注重实效的途径
2.1 重复的危害
1. DRY: 系统中的每一项知识都是必须具有单一、无歧义、权威的表示
DRY: Do not repeat yourself
2. 文档与代码：你撰写文档，然后编写代码。有些东西变了，你修订文档、更新代码。文档和代码都含有统一知识的表达
2.2 正交性
1. 正交性：如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。在设计良好的系统中，数据库代码与用户界面代码是正交的；你可以改动界面，而不影响数据库；更换数据库，而不用改动界面
2.3 可撤销性
1. 要把决策视为是写在沙滩上的，而不是把它们刻在石头上。大浪随时可能到来，把它们抹去
2. 不存在最终决策
2.5 曳光弹
1. 曳光弹:
(1) 定义: 曳光弹是一种"原型制作" 。曳光弹代码虽然简约，但是完整的，并且构成最终系统的骨架的一部分；"原型制作"是用来生成用过就扔的代码。
(2) 曳光弹并非用过就扔的代码；你编写它，是为了保留它。它含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是，一旦你在系统的各组件间实现了端到端(end-to-end)的连接，你就可以检查你离目标还有多远，并在必要的情况下进行调整。一旦你完全瞄准了，增加功能将是一件容易的事情
(3) 优点: a. 用户能够及早看到能工作的东西； b. 开发者构建了一个他们能在其中工作的结构; c. 你有一个集成平台；d. 你有了可用于演示的东西； e. 你将更能够感受到工作进展
(4) 曳光弹并非总能击中目标。但是，小段代码的惯性小，要改变它更容易、更迅速；你能够搜集关于你的应用的反馈，而且与其他方法相比，你能够花费较少代价、更为迅速地生成新的、更为准确的版本
2.6 领域语言
2.7 估算
时长 报出估算的单位
1~15天 天
3~8周 周
8~30周 月
30+周 在给出估算前努力思考一下
估算来自哪里：去问已经做过这件事情的人；在你一头钻进建模之前，仔细在周围找找也曾处在类似情况的人
理解提问内容：需要把握问题域的范围；需要养成在开始猜想之前，先思考范围的习惯
建立系统的模型：
将模型分解为组件：
给每个参数指定值：
计算答案：在计算阶段，你可能会得到看起来很奇怪的答案。不要太快放弃它们。如果你的运算是正确的，那你对问题或模型的理解就很可能是错的。这是很宝贵的信息
追踪你的估算能力：如果结果证明估算错了，不要只是耸耸肩走开。找出事情为何与你的猜想不同的原因。也许你选择了与问题的实际情况不符的一些参数。也许你的模型是错的。不管原因是什么，花一点实际揭开所发生的事情。如果你这样做了，你的下一次估算就会更好
在被要求进行估算时说什么：你说:"我等会回答你"。需要放慢估算的速度，花一点时间检查&思考