第8章：胸有成竹
软件工作量是根据规模成指数型增长的，指数大约是1.5，即：
工 作 量 = 常 数 × 指 令 的 数 量 1.5 工作量 = 常数 \times 指令的数量^{1.5}
工作量=常数×指令的数量
1.5
实践是最好地老师
实践是最好地老师，但智者还能从其他地方有收获。
第9章 削足适履
这一章讨论了内存成本问题。基本的教训是：
制定预算
确切定义模块的功能
需要有人进行宏观掌控。因为团队内的成员都是争取小红花的学生，都在局部优化自己的程序而很少考虑整体影响。
另外的措施是：
让用户选择模块，减少不需要的内存占用。
让“时间”换“空间
此外，革新的算法或者数据结构也能从根本上优化。
（不过，书中讨论的关于内存的限制情况已经和如今差别巨大。例如对于“时间”和“内存”的折中，从我个人在做交互工具的经验而言，“时间”往往比较重要，如果能用多点的“空间”来换取，一般会做这种交易。）
第10章：提纲挈领
任何管理任务的关注焦点都是：时间、地点、人员、项目内容、资金。
为什么要有正式的文档？
书面决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。
文档能够作为同其他人沟通的渠道。
项目经理的文档可以作为数据基础和检查列表。
第11章：未雨绸缪
为舍弃而计划，无论如何，你一定要这么做
唯一不变的就是变化本身
程序维护就是：前进两步，后退一步。
随着修改的增多，还可能变为：前进一步，后退一步。
第12章：干将莫邪
工具很重要，需要专门人员开发
“仿真装置”很重要
不确定性是所有情况中最糟的，因为它剥夺了程序员寻找BUG的能力
第13章：整体部分
系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命和难以察觉的BUG的主要来源。
自上而下的设计。
第14章：祸起萧墙
灾祸通常来自于白蚁的肆虐，而不是龙卷风的侵袭。项目进度经常以一种难以察觉，但是残酷无情的方式慢慢落后。
里程碑的日期选择是一个估计技术上的问题，很大程度上依赖以往的经验。
里程碑的选择只有一个原则：必须是具体的，特定的，可度量的事件，能够进行清晰的定义。
并不是每一天的滞后都等于灾难。如何判断哪些偏离是关键呢？可以采用PERT图（Program Evaluation and Review Technique）。
有两种掀开毯子将污垢展现在老板面前的方法：
减少角色冲突和鼓励状态共享。老板决不在检查状态的时候做安排。
猛地掀开地毯。建立能了解状态真相的评审机制。
第15章：另外一面
这一章强调了“文档”的重要性。即使是完全开发给自己的程序，仍然是必要的，因为记忆会衰退。
不同用户需要不同级别的文档：
使用程序。不需要了解程序的代码。
依赖程序。需要调用程序，因此需要知道程序代码的外部接口
修改程序。需要完全知道程序中代码的内部结构。
“流程图”被过分吹捧了。
自文档化的程序：
试图努力维护不同文件之间的同步关系，是一件费力不讨好的事情。 但我们在文档编制的时候违反了这一规则：程序变动总是不能及时准确地反映在文档之中。相应地解决方法就是：将文档整合到源代码中。
其实说白了，就是通过加注释等方法提高代码的可读性。如果代码非常好读懂，那就不需要文档了。
第16章：没有银弹
所有的软件活动包括：
根本任务：即打造构成抽象软件实体的复杂概念结构。
次要任务：即使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言。
目前取得的进步基本上都是“次要任务”上的，但是“根本任务”上的困难一直存在，并且可以预见在短时间内无法取得数量级上的进步。
困难的特性：
复杂度
一致性
可变性
不可见性