作者: John Sonmez 11 Rules All Programmers Should Live By
这篇文章就是一个很好的GTD实践。作者给软件开发人员制定了11条规则，非常走心。里面插入了一些simple programer的广告，但确实是干货。下面是正文：
我是一个按规则生活的人。
现在，这些规则大部分是我本人为自己设立的，但它们依然是规则。我发现为自己创建一些规则可以过得更好，因为这样做可以提前决定一些事而不是在匆忙中做出决定。
例如：我今天早上应该去健身房吗？
我的规则告诉我说我要在周三前往健身房，今天是周三，因此我要去健身房，就这么办了！
这周，当我在思考那些强加于自身的规则时，觉得制定一系列软件开发者都应遵守的规则是个好主意。
现在，我承认下面大多数规则比“指导方针”要求更多，它们是：
1: 你用技术来获取解决方案，但它（技术）本身并不是解决方案
Technology is how you get to the solution, it is not THE solution.
我们带来了最新的JavaScript框架-ahem,Angular，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.
所有问题都可以进行分解。
最佳的解决方案往往是最简单的。
但简单并不容易，简化事情需要付出努力。
本文目的在于简化复杂的软件开发和人生，这并不容易。
傻瓜为问题提出复杂的解决方案。简化解决方案需要更多的精力和耐心，但这没有错。
花点时间。多点努力。力求精简。
你遵守什么规则？
上面是我遵守的规则，那你呢？
你个人遵守什么规则？
你认为什么是重要的，应该每天牢记？
