焦油坑
1.1 编程系统产品开发的工作量是供个人使用的独立开发的构建的9倍；我估计软件构件产品化引起了3倍的工作量，将软件构件整合成完成系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。
人月神话
2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。
2.2 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
2.3 所有编程人员都是 乐观主义者：“一切都将运作良好”。
2.4 由于编程人员通过思维开发，期待在现实中不会遇到困难，但是构思本身有缺陷，因此总会有bug。
2.5 我们围绕成本核算的估计技术，混淆了工作量和项目进度。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
2.6 在若干人员中分解任务会增加额外的沟通工作量—培训和相互沟通。
2.7 关于进度安排，根据经验是1/3技术啊，1/6编码，1/4构件测试和1/4系统测试。
2.8 我们对自己的估计技术不确定，因此在管理和客户的压力下，常常缺乏坚持的勇气。
2.9 Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。
2.10 向软件项目中增派人手从三个方面增加了项目必要的工作量：任务重新分配本身和所造成的工作中断、培训新人员和额外的相互沟通。
外科手术队伍
3.1 同样有两年经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。
3.2 小型、精干的队伍是最好的—思绪尽可能的少。
3.3 两个人的团队，其中一人是领导者，常常是最佳的人员使用方法。
3.4 对于真正意义上的大型系统，小型精干的队伍太慢了。
3.5 实际上，绝大多数大型编程系统的经验显示，一拥而上的开发方法是高成本、速度缓慢、低效率的，开发出的产品无法进行概念上的集成。
3.6 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法—既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底减少了沟通工作量。
贵族专制、民主政治和系统设计
4.1 概念完整性是系统设计中最重要的考虑因素。
4.2 功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能。
4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
4.4 对于非常大型的项目，将体系结构方面的工作与具体实现相互分离是获得概念完整性的强有力方法(同样适用于小型项目)。
4.5 如果要得到系统概念上的完整性，必须要有人控制这些概念—实际上就是贵族专制统治。
4.6 纪律、规则对行业有益。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性
4.7 概念上统一的系统能更快的开发和测试。
4.8 体系结构、设计实现、物理实现的许多工作可以并发进行。
画蛇添足
5.1 尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
5.2 结构师如何成功地影响实现：牢记开发人员承担创造性的实现责任，结构师只能提出建议；时刻准备着为所指定的说明建议一种实现方法，准备接受任何其他可行的方法；准备对所建议的改进放弃坚持；听取开发人员在体系结构上改进的建议。
5.3 第二个系统是人们所设计的最危险的系统，通常倾向是过分的进行设计。
5.4 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。
贯彻执行
6.1 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定一致。
6.2 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
6.3 出于精确性的考虑，我们需要形式化设计定义，也需要记叙性定义来加深理解。
6.4 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施。
6.5 如果起初至少有两种以上的实现，体系结构定义会更加整洁和规范。
6.6 项目经理最好的朋友就是他每天需要面对的对手—独立的产品测试机构或小组。
为什么巴比伦塔会失败
7.1 巴比伦塔项目失败是因为缺乏交流以及交流的结果—组织。
7.2 交流：因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现，由于对其他人的假设，团队成员之间的理解开始出现偏差。
7.3 项目工作手册：是对项目必须产生的一系列文档进行组织的一种结构。 项目所有的文档必须是该手册的一部分。 需要尽早和仔细设计工作手册结构。 每一个团队成员应该了解所有的材料。 实时更新至关重要。
7.4 组织架构： 团队组织的目标是为了减少必要的交流和协作量。 为了减少交流，组织结构包括了人力划分和限定职责范围。 权力结构是树状结构，组织中的交流是网状结构。 每个子项目都具有两个领导角色— 产品负责人、技术主管或结构师。
胸有成竹
8.1 仅仅通过对编码部分时间的估计，乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。
8.2 构建独立小型程序的数据不适用于编程系统项目。
8.3 程序开发呈程序规模的指数增长。
8.4 当使用适当的高级语言时，程序编制的生产率可以提高5倍。
削足适履
9.1 除了运行时间以外，程序所占据的内存空间也是主要开销。特别是对于操作系统，它的很多程序是永久驻留在内存中的。
9.2 软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法。
9.3 规模预算不仅在占据内存方面是明确的，同时还应该指明程序对磁盘的访问次数。
9.4 规模预算必须与分配的功能相关联，在指明模块大小的同时，确切定义模块的功能。
9.5 在整个实现的过程期间，系统结构师必须确保连贯的系统完整性。
9.6 培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员的最重要职能。
9.7 编程需要技术积累，每个项目需要自己的标准组件库。
9.8 精炼、充分和快速的程序往往是战略性突破的结果，而不仅仅是技巧上的提高。战略上的突破常来自于对数据或者表的重新表达。数据的表现形式是编程的根本。
提纲挈领
10.1 对于软件项目，目标、用户手册、内部文档、进度、预算、组织结构图和工作空间分配是关键文档。
10.2 即使是小型项目，项目经理也应该在项目早期对上述一系列文档进行规范化。
10.3 每个文档本身就可以作为检查列表或者数据库。
10.4 项目经理的主要日常工作是沟通，而不是做出决定，文档使各项计划和决策在整个团队范围内得到交流。
未雨绸缪
11.1 第一个开发的系统对于大多数项目来说并不合用，它可能太慢、太大难以使用。
11.2 系统的丢弃和重新设计可以一步完成，也可以一起实现，但必须完成。
11.3 为舍弃而计划，无论如何，你一定要这么做。
11.4 开发人员交付的是用户满意程度，而不仅仅是实际的产品。
11.5 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
11.6 为变更计划软件产品的技术，特别是拥有最细致的模块接口文档的结构化编程广为人知。
11.7 为变更计划组织架构：为变更组建团队比为变更进行设计更加困难。
11.8 前进一步，后退两步：程序维护主要由各种变更组成，如修复设计缺陷，新增功能，或者使用环境或配置变换引起的调整。
11.9 对于一个广泛使用的程序，其维护成本通常是开发成本的40% 或更多。
11.10 缺陷修复总会以20%~30%的几率引入新的bug。
11.11 实现设计的人员越少，接口越少，产生的错误也就越少。
11.12 前进一步，后退一步：系统熵随时间增加，所有修改都倾向于破坏系统的架构，增加系统的混乱程度(熵)。
干将莫邪
12.1 项目经理应该制定一套策略，为通用工具的开发分配资源，同时，也必须意识到专业工具的需求。
12.2 需要安排一名系统程序员，保证机器上的标准软件是及时更新和实时可用的。
12.3 目标机器的使用需求量是一种特殊曲线：开始使用率非常低，突然出现爆发性增长，最后趋于平缓。
12.4 在编制程序的项目中，节省最大工作量的工具可能是文本编辑系统。
整体部分
13.1 许多失败完全源于哪些产品未经确定以的地方。
13.2 在编码前，规格说明必须提高给外部测试小组，以详细检查说明的完整性和明确性。
13.3 好的自上而下的设计从四个方面避免了bug。
13.4 有时必须回退，推翻顶层设计，重新开始。
13.5 结构化编程中，程序的控制结构仅仅由支配代码块给定的集合组成，可以有效避免bug。
13.6 系统调试相对于单元测试所花费的时间会比预料的更长。
13.7 必须有人对变更和版本进行控制和文档化，团队成员应使用开发库的各种拷贝在工作。
13.8 系统测试期间，一次只添加一个构件。
祸起萧墙
14.1 一天一天的进度落后比起重大灾难更加难以识别、不易防范，难以弥补。
14.2 根据一个严格的进度表控制住大型项目的第一步是制定进度表，由里程碑和日期组成。
14.3 里程碑必须是具体、特定和可度量的事件，能进行清晰的定义。
14.4 PERT的准备工作是PERT图使用中最有价值的部分。必须有评审机制来获取真正状态。
14.5 对于大型项目，一个对里程碑报告进行维护的计划和控制小组非常可贵。
另外一面
15.1 对于软件编程产品来说，文档和代码同样重要。
15.2 即使对于完全开发给自己用的程序，描述性文字也是必须的。
15.3 最小化文档负担的3个关键思路：借助名称和声明等来附加尽可能多的信息；使用空格和格式来表现从属和欠条关系，提高可读性；以段落注释，特别是模块标题，向程序中插入必要的记叙性文字。