图书编号 ISBN 978-7-121-12336-8
35 Finish What You Start 要有始有终
分配资源的例程也应该释放资源
类代表某个资源，构造器给予你该资源类型的特定对象，而析构器将其从你的作用域中移出。
36 Minimize Coupling Between Modules 使模块间的耦合减至最低
函数的德墨忒尔法则试图使任何给定程序中的模块之间的耦合减至最少。它设法组织你为了获得对第三个对象的方法的访问而进入摸个对象。
调用外部时，期望外部能够一口气地，直接地提供所需的数据，而无需了解外部的组成方式。
37 Configure, Don’t Integrate 要配置，不要集成
要用metadata描述应用的配置选项：调谐参数、用户偏好、安装目录，等等。元数据是关于数据的数据。元数据是任何对应用进行描述的数据。
38 Put Abstractions in Code, Details in Metadata 将抽象放进代码，细节放进元数据
也就是说，需要有一个读取元数据的模块负责导入元数据中指示的配置；意味着元数据应该有一种默认配置。
39 Analyze Workflow to Improve Concurrency 分析工作流以改善并发性
分析的一种方法是使用 UML activity diagram (UML 活动图) 。
40 Design Using Services 用服务进行设计
41 Alwayse Design for Concurrency 总是为并发进行设计
解除时间耦合
Separate Views from Models 拆分视图和模型
模块或类的一个好定义就是，它具有单一性、定义良好的责任。
MVC, Model View and Controller. 模型-视图-控制器
43 Use Blackboards to Coordinate Workflow 用黑板协调工作流
44 Don’t Program by Coincidence
- 总是意识到自己在做什么。
- 不要忙不地编程
- 按照计划行事，不管计划保存在何处。
- 依靠可靠的失误。
- 为假设建立文档。
- 不仅要测试你的代码，还需要测试假设。
- 为工作划分优先级。
- 不要做历史的奴隶，不要让已有的代码支配将来的代码。
45 Estimate the Order of Your Algorithms 估算算法的阶
在经典算法问题上，记住复杂度最优的那些算法
46 Test Your Estimates
47 Refactor Early, Refactor Often 早重构，常重构
无论何时代码出现下述情况时， 就应该考虑重构代码：
– 重复。违反了DRY原则
– 非正交的设计。
– 过时的知识。事情变了，需求转移了，对问题的理解改变了。
– 性能。
48 Design to Test
49 Test Your Software, or Your Users Will 测试你的软件，否则你的用户就得测试。
50 Don’t Use Wizard Code You Don’t Understand 不要使用你无法理解的想到代码
51 Don’t Gather Requirement – Dig for Them 不要搜集需求——挖掘他们
52 Work with a User to Think Like a User
53 Abstractoins Live Longer than Details
54 Use a Project Glossary 使用项目词汇表
与项目中不同领域的人使用共同的词表，一个名词对应一种事物。
55 Don’t Thinkd Outside the Box – Find the Box
处理中的问题比预先想的要困难很多，就好像是走错了路——一定有比这更容易的方法！或许现在你已经落后于计划，因为这个特定问题是“不可解决的”。这正是退回一步问问自己一下问题的时候：
– 有更容易的方法吗？
– 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
– 这件事情为什么是一个问题？
– 是什么使它如此难以解决？
– 它必须以这种方式完成吗？
– 它真的必须完成吗？
56 Listen to Nagging Doubts – Start When You’re Ready 倾听反复出现的疑虑——等你转备好了在开始
57 Some Things are Better Done than Described
58 Don’t Be a Salve to Formal Methods 不要做形式方法的努力
59 Expensive Tolls Do Not Produce Better Designs
60 Organize Around Functionality, Not Job Functions 围绕功能、而不是工作职务进行组织
确保一致和准确的一种很好的方式是使团队所做的每件事情自动化。如果你的编辑器能够自动在你输入时安排代码的布局，为什么要手工进行嗯？如果夜间构建能够自动运行各种测试，为什么要手工完成测试表单呢？
自动化是每个项目团队的必要组成部分。为了确保事情得以自动化，指定成员担任工具构建原，构建和部署使项目中的苦差事自动化的工具。让它们制作makefile、shell脚本、编辑器模板、实用程序，等等。
……持续更新中