第一章 注重实效的哲学
1.我的源码让猫给吃了
在所有的弱点中，最大的弱点就是害怕暴露弱点
负责：
分析风险是否超出了你的控制，对于风险太大或不可能做到的事情，你有权不去为之负责。
如果你确实同意要为某个结果负责，就应切实负起责任，并设法给出各种选择。
2.软件的熵
不要容忍破窗户
不要留着破窗户（低劣的设计，决策错误，垃圾代码）不修。发现一个就修一个。
如果没有适当的时间进行修理，就把出问题的代码放入注释，或显示”未实现“消息。或用虚设的数据加以替代。==采用某种行动防止进一步的损坏，并说明情势处在你的控制之下。
3.石头汤与煮青蛙
做变化的催化剂
设计出你可以合理要求的东西，一旦完成，就那给大家看，然后说：”要是我们增加。。。。。会更好“，假装那并不重要。坐回椅子上，等着他们开发你本来就想要的功能。
记住大图景 bigview
要持续观察周围正在发生的事情。
4.足够好的软件
使质量成为需求问题
应该给用户以机会，让他们参与决定你制作的东西何时以足够好。
如果你给用户某样东西，让他们及早使用，他们的反馈往往会把你引向更好的最终解决方案。
5.你的知识资产
6.交流
第二章 注重实效的途径
7.重复的危害
DRY原则——不要重复你自己
重复是怎样发生的
- 强加的重复——开发者觉得别无选择
- 无意地重复——开发者没有意识到他在重复
- 无耐性的重复——开发者偷懒
- 开发者之间的重复——同一团队的几个人重复了同样的信息
强加的重复
使用一些方法来尽可能（而不是完全）避免重复：
- 信息的多种表示：编写简单的元数据，过滤器，代码生成器。
- 代码中的文档：把注释保留给高级说明而不是低级知识。
- 文档与代码：用程序方式将文档与代码关联起来。
- 语言问题：C和C++需要在接口规范与实现之间重复接口信息。应该在头文件中机子啊接口信息，在实现文件中记载使用者无需了解的细节信息。
无意的重复
有时重复来自设计中的错误
当出现互相依赖的数据元素时，最好让其中一些元素变为计算字段。
应为性能原因违反DRY原则时，需要确保其影响局部化，不会暴露给外界
无耐性的重复
让复用变得容易
开发者之间的重复
设置论坛，用以讨论常见问题，交换意见，进行提问；让某个团队成员担任项目资料管理员，其工作时促进知识的交流。在源码树中指定一个中央区域，用于存放实用例程和脚本。一定要阅读别人的代码和文档。
8.正交性
第五章 弯曲，或折断
27.元程序设计
再多的天才也无法胜过对细节的关注。
动态配置
==——要配置，不要集成。==
要用元数据描述应用的配置选项：调谐参数，用户偏好，安装目录，等等。
元数据驱动的应用
为一般情况编写程序，把具体情况放在别处——编译的代码库之外。
这种方法有若干好处：
- 迫使你解除你设计的耦合，从而带来更灵活，可适应性更好的程序。
- 迫使你推迟对细节的处理，创建更健壮，更抽象的设计。
- 无需重新编译应用，就可以对其进行定制。可以利用这种定制，轻松绕开正在运行的重大bug
- 与通用编程语言相比，可以通过一种更接近问题领域的方式表示元数据。
- 可以使用相同的引擎，搭配不同的元数据，来实现不同的项目。
商业逻辑
考虑某种基于规则的系统中对工作流进行编码，并嵌入到应用中。这样，你就可以通过编写规则，而不是修改代码来配置他。
对于不那么复杂的逻辑，可以使用小型语言加以表达，从而消除在环境变化时重新编译和重新部署的需要。
不要编写渡渡鸟代码
没有元数据，程序就不可能获得应有的适应性与灵活性
