第4章：贵族专制、民主政治和系统设计
概念的完整性是系统设计中最重要的考虑因素
第5章：画蛇添足
在开发第1个系统时，结构师倾向于简洁，之后不断产生装饰和润色。第二个系统是最“危险”的，往往会过度设计。而随后的系统由于之前的经验会相互验证，因此能识别出不够通用的部分。
第6章：贯彻执行
设计结果必须由一个人或两个人完成，以确保这些决定是一致的。
确保贯彻执行：
手册
形式化定义
直接整合到代码
会议
多重实现
电话日志
产品测试
第7章：为什么巴比伦塔会失败
为什么？因为缺少交流。文档（手册）很重要。
但有一种看法认为：编程人员只了解自己负责的部分效率更高。确实，但这要求精确，完整地定义所有地接口。
【产品负责人】&【技术主管】
第8章：胸有成竹
软件工作量是根据规模成指数型增长的，指数大约是1.5，即：
工 作 量 = 常 数 × 指 令 的 数 量 1.5 工作量 = 常数 \times 指令的数量^{1.5}
工作量=常数×指令的数量
1.5
实践是最好地老师
实践是最好地老师，但智者还能从其他地方有收获。
第9章 削足适履
这一章讨论了内存成本问题。基本的教训是：
制定预算
确切定义模块的功能
需要有人进行宏观掌控。因为团队内的成员都是争取小红花的学生，都在局部优化自己的程序而很少考虑整体影响。
另外的措施是：
让用户选择模块，减少不需要的内存占用。
让“时间”换“空间
此外，革新的算法或者数据结构也能从根本上优化。
（不过，书中讨论的关于内存的限制情况已经和如今差别巨大。例如对于“时间”和“内存”的折中，从我个人在做交互工具的经验而言，“时间”往往比较重要，如果能用多点的“空间”来换取，一般会做这种交易。）
第10章：提纲挈领
任何管理任务的关注焦点都是：时间、地点、人员、项目内容、资金。
为什么要有正式的文档？
书面决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。
文档能够作为同其他人沟通的渠道。
项目经理的文档可以作为数据基础和检查列表。