我是一个倾向于生活在规则下的人。
现在，这些规则大部分是我本人为自己设立的，但它们依然是规则。
我发现为自己创建规则可以让我过得更好，因为这样做可以提前决定一些事情，而不是要在匆忙中做出所有的决定。
我今天早上应该去健身房吗？
我的规则告诉我说我要在周三前往健身房，今天是周三，因此我要去健身房，就这么办了！
这周，当我正在思考那些对我施加有影响的规则时，我想到了去制定一系列软件开发者都应该遵守的规则，我认为这可能是一个好主意。
现在，我承认，这里面的大多数规则比那些“指导方针”要求的要多，它们是：
1: 技术是用来让你获取解决方案的，但它本身并不是解决方案
Technology is how you get to the solution, it is not THE solution.
我们带来了最新的JavaScript框架，IoC容器，编程语言或者甚至是操作系统，但是所有这些并没有实际解决我们作为一个尝试解决问题的程序员的问题，取而代之的是更简单的工具帮助我们解决问题。
我们对于特定的技术必须非常谨慎不要太疯狂，不是我们碰巧喜欢或者碰巧现在很流行，而是要考虑运行他们所带来的风险，要思考这个问题是不是就是那个钉子，而我们是不是碰巧拿着锤子，那么我们就要学习它。
2: 对代码而言，“聪明”是“清晰”的敌人
Clever is the enemy of clear.
在写代码的时候，我们应努力保持书写的代码清晰易懂。
可以明确（Clear）表明自身意图的代码，永远要比那些晦涩的代码更有价值——无论那些晦涩的代码被构建得多么聪明（Clever）。
虽然情况并不总是这样，但一般来说，“聪明”是“清晰”的敌人。
一种经常出现的情况是，当我们写出一段“聪明”的代码时，这段代码并不是特别的“清晰”。
这条规则非常重要，尤其是当我们思考我们要做一些特别“聪明”的事情时。
有时候我们写出了“聪明”的代码，它们同时也是清晰的，但是其他情况也会时有发生。
如果你对写出简洁的代码感兴趣，我高度推荐你用下面这本书上描写的规则来检验：Robert C. Martin的《干净的编码者：专业程序员的行为守则》（The Clean Coder: A Code of Conduct for Professional Programmers）
3: 只在逼不得已的情况下才写代码
Only write code if you absolutely have to.
这条可能会有些争议，毕竟，作为程序员，我们的工作不就是写代码吗？
嗯。。。这个看你怎么说了。
写代码的确是我们工作的一部分，但是，我们要尽可能努力的去用最少的代码来解决问题。
所谓“最少的代码”并不是说我们只能用一个字母的变量名或者其它方式来压缩我们的代码。“最少的代码”指的是我们应该只写为了实现功能而必不可少的代码。
我们常常添加一些“酷”的功能，来让代码“健壮”和“灵活”，让代码能够处理“所有”可能的使用情况。我们企图猜测那些可能会被用到的功能。总之，我们常常花费时间去解决一些头脑中臆想出来的可能的情况。
我们这么做，是错的。
不能否认，这些多余的代码能会带来些好处。然而，这些代码同样的会有很多危害。我们写的代码越多，就越有可能引入错误；我们写的代码越多，将来的维护工作就越繁杂。
好的软件工程师只写绝对需要的代码。
伟大的软件工程师会把没用的代码统统都删掉。
4: 注释是魔鬼
Comments are mostly evil.
我并不是很热衷于写注释。当我跟Bob Martin在一起时，他说：
“你写的每个注释，都代表着你表达能力的欠缺“ －《整洁代码：敏捷软件艺术手册》
这并不是说一点注释也不写，但通常我们可以通过一种更好的方式——命名来避免。
注释仅在命名不能有效表示变量或方法的意图时才真正需要。此时的注释表达了不能用代码表达的真实意图。
例如，注释能够告诉你在代码中某些奇怪的操作顺序并不是错误的，它是由于底层系统的某一bug而有意为之的。
但通常，注释不仅没有必要，有时它们还会"撒谎"。
注释没有随着代码更新的倾向，而这是很危险的，因为它们会将你带入歧途。
你会检查每条注释和与之对应的代码，确保代码是在做注释说的事么？如果是的话，写注释还有什么用？如果不是，你怎么相信注释说的是对的？
真他妈麻烦，所以最好还是尽量别写注释了。
5: 永远要在你开始写代码前考虑好它是做什么的
Always know what your code is supposed to do before you start writing it.
这一条看上去显而易见，然而事实并非如此。
想想你有多少次并没有完全想好就坐下来写代码，而这段代码确实实现了你要做的功能？
比之我乐于承认这个思路的正确性，我行动了更多次，这是一条我需要经常去品读的规则。
练习测试驱动开发（Test Driven Development，TDD）在这里会有所帮助，因为你在写出代码前，必须逐字的了解它们会做些什么，但是这依然无法阻止你去做错的事情。因此，在构建一个特性或功能前，保证自己百分之百地理解需求，也是很重要的。
6: 在交付之前，测试你的代码
Test your sh—code before you ship it.
别把你的代码直接扔给QA，然后指望着所有人来浪费时间为你服务。
事实上，你自己认真的运行一下测试案例，是完成代码之前必不可少的一步。
这并不是说一定让你自己找到代码中所有的问题，但是你至少得把那些愚蠢得令人尴尬的错误找出来吧？
很多软件工程师都觉得测试代码是QA的工作。这个想法绝对是大错特错。保证代码的质量，是每个人的工作！
7: 每天学点新东西
Learn something new every day.
如果你每天都不学新知识，你就在退步，因为我可以保证你会忘记一些东西。
每天学一些新东西，并不会花去你太多的时间。
试着花15分钟去读一本书——我去年读了一大堆书，平均每天要花45分钟在阅读上。
每天的小进步，随着时间的推移会积少成多，并在很大程度上重塑你的未来。如果你想在未来获取回报，你现在就需要开始投资了。
此外，今天的技术变化非常之快，如果你不能做到不断提高已有技能并学会新的技能，你会很快掉队。
8: 写代码是件快乐的事
Writing code is fun.
诚然，你最开始进入这个行业可能只是因为它待遇优厚。
我是说，为了良好的待遇找工作没有任何错误，但是医生或律师可能会是更好的选择。
你之所以成为了一名软件开发人员，是因为你爱写代码。因此，不要忘记你在做你所热爱的事情。
写代码有很多乐趣，我希望我能写更多的代码。
我这几天经常忙于写代码并试图让它占据我更多的时间，这也是我为什么如此清晰地记得它有多么的有趣。
也许你已经忘记了写代码的乐趣，也许是时候你应该再次记起写代码是多么的有趣了——通过开始一个边角的项目，或是仅仅改变你的心态，意识到你开始写代码了，并为之付出。（但愿如此）
9: 你无法完全了解它
You can’t know it all.
无论你学了多少知识，都会有大量你所不知道的东西。
认识这一点非常重要，因为你可以驾驭你的那些想要去学会所有东西的发狂的想法。
没能获取所有问题的答案，这挺好的。
在自己不理解某事时寻求帮助或说出来，这也挺好的。
在很多情况下，你可以相当接近地了解到你想知道的事情——相信我，我一直在这样做。
我的观点是，不要总想着学会一切——如果这是个不可能完成的任务。相反，你应该重点学习那些你需要去知道的东西，并且提升那些可以让自己学习速度加快的能力。
10: 最佳实践要因地制宜
Best practices are context dependent.
测试驱动开发是你最拿手的编程方式么?
我们应该一直采用结对编程?
不使用IOC容器你就不好编了?
这些问题的答案是“看情况吧”。
具体情况具体分析。
人们会将所谓的“最佳实践”强推给你，并且他们经常说这些很实用——你应该经常这样做或那样做——但这是不对的。
当我写代码时我会遵循很多”最佳实践“，但有时我也会背离它们。
原则是永恒的，最佳实践是变通的。
11: 力求精简
Always strive to simplify.
所有问题都可以进行分解。
最佳的解决方案往往是最简单的。
但简单并不容易，简化事情需要付出努力。
本文目的在于简化复杂的软件开发和人生。
相信我，这并不容易。
傻瓜为问题提出复杂的解决方案。简化解决方案需要更多的精力和耐心，但这没有错。
花点时间。多点努力。力求精简。
你遵守什么规则？
上面是我遵守的规则，那你呢？
你个人遵守什么规则？
你认为什么是应该天天都记住的？
)
