编程从业五年的十四条经验，句句朴实

编程从业五年的十四条经验，句句朴实

排列不分先后：

1. 当性能遇到问题时，如果能在应用层进行计算和处理，那就把它从数据库层拿出来。排序和分组就是典型的例子。在应用层做性能提升总是要比在数据库层容易的多。就像对于MySQL，sqlite更容易掌控。

2. 关于并行计算，如果能避免就尽量避免。如果无法避免，记住，能力越大，责任越大。如果有可能，尽量避免直接对线程操作。尽可能在更高的抽象层上操作。例 如，在iOS中，GCD，分发和队列操作是你的好朋友。人类的大脑没有被设计成用来分析那些无穷临时状态——这是我的惨痛教训所得。

3. 尽可能简化状态，尽可能局部本地化。适用至上。

4. 短小可组合的方法是你的好朋友。

5. 代码注释是危险的，因为它们很容易更新不及时或给人误导，但这不能成为不写注释的理由。不要注释鸡毛蒜皮的事情，但如果需要，在某些特殊地方，战略性的长篇注释是需要的。你的记忆会背叛你，也许会在明天早上，也许会在一杯咖啡后。

6. 如果你认为一个用例场景也许“不会有问题吧”，它也许就是一个月后让你在发布的产品中遭受惨痛失败的地方。做一个怀疑主义者，测试，验证。

7. 有疑问时，和团队中所有相关人交流。

8. 做正确的事情——你通常会知道这指的是什么。

9. 你的用户并不傻，他们只是没有耐心理解你的捷径。

10. 如果一个开发人员没有被安排长期的维护你们开发的系统，对他保持警惕。80%的血、汗、泪水都是在软件发布后的时间里流的——那时你会变成一个厌世者，但也是更聪明的“行家”。

11. 任务清单是你的好朋友。

12. 主动让你的工作更有乐趣，有时这需要你付出努力。

13. 悄无声息的崩溃，我仍然会为此从噩梦中惊醒。监控，日志，警报。清楚各种的假警报和不可避免的感觉钝化。保持你的系统对故障的敏感和及时警报。

14. 复杂是大敌。

*边注：Rich Hickey先生的谈话和Robert Martin先生的《Clean Code（代码整洁之道）》一书最近给我的工作带来了非常积极正面的影响。

[英文原文：  14 lessons after five years of professional programming ]

14 lessons after five years of professional programming

In no particular order:

1. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. EDIT Some great comments on HN for this one so I felt like I better clarify: we only do this for certain queries not to improve necessarily the client response time, but to relieve load if the query is battering the DB and making it a significant bottleneck for ALL clients.

2. Concurrency, avoid it if you can. If not, then remember that with great power comes great responsibility Avoid working directly with threads if you can. Work at a higher level of abstraction if possible. In iOS, for example: GCD, dispatch and operation queues are your friends. The human mind was not designed to reason about infinite temporal state—I get nauseous thinking about how I learned all this first hand.

3. Minimize state as much as possible, and keep it as localized as possible. The functionalists were/are onto something.

4. Short composable methods are your friend.

5. Comments are dangerous since they can get out of date and mislead, but so is not having them. Don’t comment the trivial, but strategically write paragraphs if needed in specific sections. Your memory will fail you, as soon as tomorrow morning, even after coffee.

6. If you feel one use-case scenario will “probably be ok”, that’s the one that’s going to lead to catastrophic failure a month in production. Trust your paranoid gut, test and verify.

7. When in doubt, over communicate all concerns with your team.

8. Do the right thing—you usually know what that thing is.

9. Your users aren’t stupid, they just don’t have the patience for your cut corners.

10. If an engineer is not tasked with the long term maintenance of the systems they build, view them with suspicion. 80% of the blood, sweat, and tears of software occurs after its been released—that’s when you become a world weary, but wiser “professional.”

11. Checklists are your friends.

12. Take initiative to purposeful enjoy your work, sometimes this will take effort.

13. Silent failures, I still have nightmares. Monitor, log, alert. But be wary of false positives and the inevitable desensitization it leads to. Keep your system senses clear and alert.

14. At the end of the day, we’re paid to manage complexity. Work accordingly.

*Side note: talks by Rich Hickey and Clean Code by Robert Martin have been very positive recent influences on my work.