第三章：三思而后行：前期准备
3.1：计划的重要性是不言而喻的，需要明确的是：软件不仅仅是开发代码。创建高质量的架构活动需要一定的技能，这些技能不是轻而易举能够获得的，某些准备工作也需要特定的人来做。优秀的程序员永远是紧缺的，当更好的机会摆到面前的时候，在一个蛮荒的软件企业中工作是不明智的（欢迎来阿里云，简历发到longtask@gmail.com,呵呵）。软件错误的积累就如同食物链一样，越到食物链顶端，累积的有害物质越多，软件开发过程中，发现错误的时间要尽可能的接近引入该错误的时间。例如：修复一个架构缺陷大概需要￥1000，在系统测试修复这个缺陷就可能花费￥15000。
3.2：对于绝大多数项目来说，各种活动有一定的重叠，多数项目中采用迭代式开发（Scrum）比序列式开发更加的节约成本。
3.4：据IBM和其他公司研究表明：项目中需求变化会有25%，拥抱变化吧...对待需求，需要让每个人知道需求变化的代价，建立一套变更控制程序，使用能适应变更的开发方法，适当的时候可以放弃该项目。
3.5：【如果你不能向一个六岁的孩子解释某件事，那么自己就没有真正的理解它。--爱因斯坦】软件架构也是如此，需要让程序员理解相关架构。优秀的架构规格书的特点在于，讨论了系统中的类，讨论了每个类背后的隐藏信息，讨论了“采纳和排斥所有可能的设计替代方案”的根本理由。要抛弃“我们向来这样做”的自以为是的说法（betch炖肉菜谱的案例）。架构应该踏在对系统“欠描述”和“过度描述”之间的那条分界线上。
3.6：如果碰到客户这样说：“我不能告诉你我想做什么，不过我想知道我需要花多少钱。”或者是“开发个twitter需要花多少钱？”，你应该转身回家玩游戏。
第四章：关键的“构建”决策
编程语言的选择会在多方面影响生存率和代码质量。要结合语言的优势去写相关的代码，例如：和unix系统打交道，用下python，大中型管理系统，用java...
编程约定也很重要，达到架构编码的一致性和提高程序的可读性。{约定优于配置（Convention over Configuration）是另外的东东了}
“深入一种语言去编程”和“不要仅在一种语言上编程”一样的重要。