这里并没有特定的顺序:
1. 当遇到性能问题时,如果可以在应用程序层上评估或处理,那么就把它从数据库层中拿出来."按XX排序"和"按XX组合"就是典型的例子. 应用程序层总是比数据库层容易测量.这对服务器上的MySQL和手持设备上的SQLite都是一样的.HackerNews上有一些很好的评论,所以这里我澄清一下:我们仅为了某些特定的查询做这些,不是为了提升某个客户的反应速度,而是为了减轻复荷, 如果这个查询严重破坏数据库并且对所有用户都是有重大意义的瓶颈.
2. 尽可能避免并发. 如果实在不行,要记住能力越强责任越大.尽量避免直接使用线程. 如果有可能的话要使用更高一层级的抽象. 例如在iOS中,GCD, dispatch和operation queue就是很好的帮手.人类的大脑不能用来思考无尽的临时状态,一想到我亲手学习到这条经验的经历时就感觉到恶心.
3. 尽可能少用状态,并且要保持它们在局部.实用主义者是映射到某种东西之上的.
4. 短小,可组合的方法是你的朋友.
5. 注释是危险的因为它们很容易过时和误导,但是没有注释也是同样危险的.不要对琐碎的进行注释,但是如果在某个特定的部分需要,就要有策略性的写上几段.一到明天早上你的记忆就会让你失望的,尽管已经喝了咖啡.
6. 如果你感觉一个用例会"可能Okay", 那个就是那种会在产品里面一个月就引起一次灾难性的失败.相信你过分怀疑的勇气,测试然后验证.
7. 当有疑问时,与你的团队沟通掉所有的顾虑.
8. 做正确的事,你通常都知道是什么事.
9. 你的用户并不傻,他们只是对你的"简便方法"没有耐心而已.
10. 如果一个工程师没有被指派过他们创建的长期系统的维护工作, 对他们要持怀疑态度. 软件当中的80%的血汗和泪都是出现在软件发布之后, 那就是当你变成一个疲惫不堪的但是更聪明的"专业人员"的时候.
11. 清单是你的朋友.
12. 主动的有明确目的地享受你的工作, 有时这需要一些努力.
13. 对于无声的失败,我仍还会做恶梦. 监视器, 日志, 警告. 但是对于假成功和它带来的难免的脱敏要保持谨慎. 保持你系统的识别力是清晰的和警觉的.
14. 在一天结束时,付钱给我们是要去解决复杂问题.所以要按事情的重要程度去工作.