第七章的主题是为什么巴比伦塔会失败？书中写道巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。在日常编码中我们要明白团队的重要性，团队在一个完美的项目中是不可缺少的存在，在团队中要学会交流，不要“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差，团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。以及电子邮件。其次就是项目工作手册， 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。每一个团队成员应该了解所有的材料（工作手册）。
第八章主题是胸有成竹。仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。构建独立小型程序的数据不适用于编程系统项目。软件工作量是根据规模成指数型增长的，指数大约是1.5，即：工作量 = 常数 \times 指令的数量^{1.5}。实践是最好地老师实践是最好地老师，但智者还能从其他地方有收获。
第九章主题是削足适履这一章讨论了内存成本问题。基本的教训是：1.制定预算 。2.确切定义模块的功能。3.需要有人进行宏观掌控。因为团队内的成员都是争取小红花的学生，都在局部优化自己的程序而很少考虑整体影响。另外的措施是：1.让用户选择模块，减少不需要的内存占用。2.让“时间”换“空间。此外，革新的算法或者数据结构也能从根本上优化。
第十章主题是提纲挈领。任何管理任务的关注焦点都是：时间、地点、人员、项目内容、资金。为什么要有正式的文档？1.书面决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。2.文档能够作为同其他人沟通的渠道。3.项目经理的文档可以作为数据基础和检查列表。
第十一章是未雨绸缪。主要讲的是：为舍弃而计划，无论如何，你一定要这么做。唯一不变的就是变化本身。程序维护就是：前进两步，后退一步。随着修改的增多，还可能变为：前进一步，后退一步。
读完这五章，一定要建立团队意识，一个人是干不成大事的，要学会在团队中交流，增强语言表达的能力。其次就是要未雨绸缪，要有计划，有方向。
标签：读后感,神话,项目,交流,文档,团队,工作手册 From： https://www.cnblogs.com/mine-my/p/17274725.html