原文来自 http://www.oschina.net/news/39728/14-lessons-after-five-years-of-professional-programming
1. 当性能遇到问题时，如果能在应用层进行计算和处理，那就把它从数据库层拿出来。排序和分组就是典型的例子。在应用层做性能提升总是要比在数据库层容易的多。就像对于MySQL，sqlite更容易掌控。
这是仅次于直觉的选择，当性能问题的时候，第一感觉肯定是加机器加硬件，然后就到根据业务逻辑拆分数据结构，在应用层提高速度。优点是比较直接，在一定程度上是个好方法；缺点也同样明显，会提高应用层的复杂度和减低可维护性。
2. 关于并行计算，如果能避免就尽量避免。如果无法避免，记住，能力越大，责任越大。如果有可能，尽量避免直接对线程操作。尽可能在更高的抽象层上操作。例 如，在iOS中，GCD，分发和队列操作是你的好朋友。人类的大脑没有被设计成用来分析那些无穷临时状态——这是我的惨痛教训所得。
最新的语言，也在朝这个方向发展。似乎是个好方法，越是抽象层次高，那么针对业务的解决能力就越大。这需要权衡，抽象层次越高，意味着底层离得越远，编程能力无法得到锻炼，另外是有些底层问题也是无法从高层解决。
3. 尽可能简化状态，尽可能局部本地化。适用至上。
以用为本的说法，无可厚非。但是没有什么指导作用，该怎么干还是怎么干，很多时候解决方法只有一个，选择没有想象中那么多。
4. 短小可组合的方法是你的好朋友。
但是可组合的组件越来越多，你会很混乱。
5. 代码注释是危险的，因为它们很容易更新不及时或给人误导，但这不能成为不写注释的理由。不要注释鸡毛蒜皮的事情，但如果需要，在某些特殊地方，战略性的长篇注释是需要的。你的记忆会背叛你，也许会在明天早上，也许会在一杯咖啡后。
注释不是文章，如果明天早上你需要这个文章，不如记到本子里面。注释是要提醒“人”，达到这个目的就行。注释更新是个问题。
6. 如果你认为一个用例场景也许“不会有问题吧”，它也许就是一个月后让你在发布的产品中遭受惨痛失败的地方。做一个怀疑主义者，测试，验证。
这是废话，如果无论如何还是“这肯定有问题”，那么世界上没有任何一个系统可以上线使用。
7. 有疑问时，和团队中所有相关人交流。
在任何时候，都要和团队交流。
8. 做正确的事情——你通常会知道这指的是什么。
找出正确的事情，已经是成功一半了，但是很多时候问题就是在找出正确的事情。
9. 你的用户并不傻，他们只是没有耐心理解你的捷径。
不是绝对，用户的耐心和感兴趣的程度是成正比的，所以给用户更多的兴趣，比纠结于用户到底有多少耐心更重要。
10. 如果一个开发人员没有被安排长期的维护你们开发的系统，对他保持警惕。80%的血、汗、泪水都是在软件发布后的时间里流的——那时你会变成一个厌世者，但也是更聪明的“行家”。
用人不疑，对开发人员的“警惕”，使得大量的方法论，过程学，规章制度大行其道。可是最终，开发人员也是人，只要用心对待，人还是能和人沟通和理解的。
11. 任务清单是你的好朋友。
时间管理是程序员最有力的工具，也是人类最有力的工具。
12. 主动让你的工作更有乐趣，有时这需要你付出努力。
的确，努力工作和努力改善工作，是同等重要的。
13. 悄无声息的崩溃，我仍然会为此从噩梦中惊醒。监控，日志，警报。清楚各种的假警报和不可避免的感觉钝化。保持你的系统对故障的敏感和及时警报。
做好自己该做的就行，程序员是具创造力的人群，而不是消防队的警铃。
14. 复杂是大敌。
不复杂，怎么面对日益膨胀的人员架构？^_^