第一部分 打好基础
第2章 隐喻
重要的研发成果常常产自类比（analogy）。通过把你不太理解的东西和一些你较为理解、且十分类似的东西做比较，你可以对这些不太理解的东西产生深刻的理解。这种使用隐喻的方法叫做“建模”。
目前最合适隐喻：建造软件（Building Software）
第3章 前期准备（ Measure Twice, Cut Once）
测试只是完整的质量保证策略的一部分，而且不是最有影响的部分。
迭代开发往往能够减少“前期准备不足”造成的负面影响，但它不能完全消除此影响。
如果需求变更过于频繁，就建立一套变更控制程序（流程）。
错误处理
架构中应该清楚地说明一种“一致地处理错误”的策略。监测到一个错误时，应该“说”出来。
过度工程
在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。
变更策略
架构应当清楚地描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最有可能增强的功能同样也是最容易实现的”。
质量
你不应该担心架构的任何部分。架构不应该包含任何仅仅为了取悦老板的东西。它不应该包含任何对你而言很难理解的东西。你就是那个实现架构的人；如果自己都弄不懂，那怎么实现它？