人月神话读后感2
这两天把人月神话的每一个章节都读了一下，可能是因为没有做过大项目的原因吧，有很多地方都不是很懂，所以也谈不上是读后感，只能说是阅读笔记吧。
人月神话这一章，作者主要介绍了软件开发项目在进度安排上经常出现的问题。首先，由于我们对项目开发的进度估计过于乐观，我们估计出来的工作量通常会低于实际需要的工作量，尤其是对测试所需时间的安排往往是进度估算失误的最严重的地方，这应该是很多有经验的开发者会在估时的时候乘以一个固定的系数的原因。其次，人员和时间的关系并非总是反比的关系，如果任务属于可以完全分解的理想状态话，是可能达到人员和时间成反比的，但是，复杂的任务常常难以分解，那任务中的沟通需求也会占用时间，甚至可能导致人员越多，项目所需的时间越长。这是整本书让我印象最深刻的地方，还是应该根据实际情况来确定最合适的方案。
外科手术队伍这一章，基于上一章的结论：更大的队伍不一定能带来更快的开发进度。那什么样的队伍才合适成为一个问题，小团队固然高效，但是一个小团队在合理的时间内去开发一套完整的操作系统是很难的。作者在这一章里给出了解决方案：将大项目合理地划分成更小的系统，各个外科手术队伍分别开发这些更小的系统。
贵族专制、民主政治和系统设计，接上一章：短小精干的队伍带来了新的问题，如何对大项目进行合理的分割。这依赖于一个很重要的前提：概念的完整性。具体而言是指在项目开发过程中，应该有一个一以贯之的明确的目标和清晰界定的范围。而贵族专制，即少数人决定一个概念并厘清边界，然后据此分割执行就可以保证概念完整性。
画蛇添足这一章，主要是说不要过度设计，尤其是在第二个系统中保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主，保持初心。
贯彻执行这一章，概念的完整性在系统的实现人员中，也要充分传达。不理解业务背景，开发者也很难写出优秀的代码。作者在这一章介绍了很多方法，包括规格说明手册、形式化定义、会议和大会、多重实现、电话日志、产品测试，这些方法对我来讲都比较难理解。
为什么巴比伦塔会失败这一章，巴比伦塔的失败是因为上帝给了人类不同的语言导致的沟通失效。关于大型项目中如何保证沟通的顺畅，作者详细介绍了项目工作手册的内容、发布方式、更新方式等等，结合作者的年代，这部分应该已经不再是问题了。但是保持文档的更新和有效获取仍然很重要，否则不同的人对需求的记忆和理解可能出现偏差、进度可能会出现错位等等，导致项目的开发进度被拖慢。
胸有成竹这一章，是介绍对变成效率的量化的，种种量化方法将程序员的生产效率细化到指令/年，方法是工作量=常数*指令数量^1.5，就是工作时长跟代码数量的指数关系。这里我也不是很懂，可能跟项目的效率计算有关系吧。
削足适履这一章，主要是讲程序大小的，包括代码大小和内存占用的大小。我不太清楚这一部分为什么要考量，查阅书评得知，当年的那些经验在前端领域适用的已经不多了，但是在客户端领域可能仍然适用，内存主要考虑的也是泄露的问题，计算机硬件的进步真的极大地降低了软件工程的难度。
提纲挈领，这一章主要是介绍文档的重要性。在于明确的书面记录会让分歧更明朗，使混沌的状态变得清晰、明确；文档降低了沟通的负担；文档便于项目经理跟踪项目的进度状态。
未雨绸缪，这对于程序员来说可能是一个十分不幸的消息：系统必然会面对各种变化，你开发的软件必然会在修修补补中变得面目全非。无论是多么良好设计的系统，都会走向混乱，区别只是这个过程的快慢而已。因此，好的设计会让这个过程尽可能地慢，我们能做的就是眼光尽量放长远，让我们的代码尽可能地具有高可扩展性并且易于维护。而且，在面对不得不进行的重构时，做好心理准备。
干将莫邪这一章，主要说好的开发工具和开发环境可以极大地提高开发效率。
整体部分这一章，将整体的项目分割成更小的部分来开发，但是最终仍要将这各个部分合并成一个整体，这就带来了新的问题：各个部分可能独立工作良好，但是当合并成整体时导致新的系统级的bug。这就要求我们在设计系统结构时精心设计，减少各个部分间的耦合，各个模块的独立性越高，系统级的bug的可能性就越低。此外作者在本章还介绍了一些测试的方法，这部分我不太了解。
祸起萧墙这一章，项目的进度很有可能因为各种各样不可避免的因素滞后，有的时候甚至可能不知不觉就会落后，难以察觉地落后一点点，累积起来整个项目的完成就会遥遥无期。避免这种难以察觉的落后的办法是制定里程碑，将项目的进度安排划分成一个个阶段并清晰地界定各个阶段需要完成的任务。
另外一面这一章，除了面向开发者的项目文档和说明之外，软件开发也需要编写详尽的面向用户的文档，包含软件的目的、运行环境、输入输出范围、实现的功能和使用的算法、输入输出的格式、操作指令、选项、运行时间、输出结果的精度和校验方式等等，此外，还需要充分的测试用例来说明程序的功能和边界。
没有银弹这一章，没有银弹是一个广为流传的软件开发的原则，指在未来的十年内（1986-1996），没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上去的数量级的提高。作者做出这一论断的前提是：所有软件包括根本任务和次要任务，根本任务是打造构成抽象软件实体的复杂概念结构，次要任务是用编程语言表达这些抽象实体。很多技术或管理上的进展在解决次要任务上发挥了巨大作用，但是在主要任务上却进展寥寥，作者分析了原因，分别从复杂度、一致性、可变性、不可见性论述了观点。
