焦油坑
恐龙、猛犸象、剑齿虎在焦油中挣扎，他们挣扎的越猛烈，焦油纠缠的就越紧，没有那种猛兽足够强壮或具有足够的技巧，能够挣脱舒服，他们最终都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型或强壮的动物在其中剧烈地整张
作为本书的第一章，作者描述了一个各种动物在焦油坑中挣扎的场景，我的理解是如果软件开发方法不对，多么强大的软件工程师也会被其纠缠进去。
人月神话
用人月作为衡量一项工作的规模是一个危险和带有欺诈性的神话，它暗示着人员数量和时间是可以相互替代的。
向进度落后的项目中增加人手，只会使进度更加落后
在软件工程课程上我们学习过用人月这一个单位来评估软件开发规模，如果没有团队开发的经验很容易陷入人数和时间是可以互换的误区，就如同算法中时间和空间那样。但是在实际项目开发过程中，如果中期发现进度缓慢，这个时候去盲目地增加人手可能适得其反（除非是完全可以分解的任务）。
这一点比较有体会，曾经在开发某系统时发现时间比较紧迫，有同学向我提供帮助，本是一件好事，但最终却适得其反，因为对方对此系统几乎一无所知，对已完成的工作也不太清楚，我们需要花费相当多的时间来向其解释。
外科手术队伍
效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平
这部分给出了一种开发团队的架构
- 对于小型系统，开发团队应简而精
- 对于大型系统，采用外科手术团队
外科手术团队构成（10人）：
- 外科医生（首席程序员）
- 副手
- 管理员
- 编辑
- 两个文秘分别给管理员和编辑
- 程序职员
- 工具维护人员
- 测试人员
- 语言学家
贵族专制、民主政治和系统设计
这部分不是很理解emm
概念完整性: 为了反映一系列连贯的设计思路，宁可忽略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕他们其实包含着许多很好的设计。
为什么要获得概念的完整性：
1. 定义系统的易用性：易用性 = 功能 / 理解的复杂度
2. 所以当功能一定时，理解的难度越低，系统约易用，而概念越完整系统就会更加简洁直白。
该有谁来指定结构？
“精英”而非具体的实现人员，尽管实现人员也会有很多好的创意，但是为了维护系统概念的完整性必须放弃。
画蛇添足
需要制约结构师的创造性热情，这会使得系统变得复杂
结构师在开发第一个系统时会倾向于简洁精炼，而第二个系统将是最危险的系统，他们会向系统添加很多修饰功能和想法，导致系被过分设计。
结构师与开发成员的交互准则
- 牢记开发人员承担创造性和发明性的实现责任，因此结构师只能建议不能支配
- 时刻准备着为指定的说明建议另一种实现方法，同时准备接收其他任何能达到目标的方法
- 对上述的建议保持低调和不公开。
- 准备放弃坚持所做的改进建议
贯彻执行
如何保证每个开发人员都能听到、理解并实现结构师的决策？这一部分给出了一些解决方案
- 编写文档化的规格说明
- 形式化定义
- 直接整合（约定接口）
- 会议
- 电话日志（开发人员不确定时直接联系结构师，结构师记录问题并整合然后分发给用户和实现人员）
- 测试 测试人员去发现一些没有贯彻落实的地方