《人月神话》之读后感想

读了Brooks的《人月神话》一书，很有感触，记录下自己印象深刻的观点并结合自己的职场经验分析一下。

0. 人月神话

     在阅读《人月神话》之前，只理解“人月”是指项目时间安排的单位，没太注意“神话”的含义。通读了全文后，才懂了其中的见解：Brooks认为，项目开发中，人和月是不能互换的，人和月互换就是个神话(不可能实现)。需要1个人5个月完成的项目，5个人在一个月内一般是完不成的，这个观点基于的理由是：有些任务不能拆分，不能并行去进行，需要时序，需要过程。书中举了一个通俗的例子：一个女人9个月可以孕育一个小孩，但是9个女人一个月不能孕育一个小孩，即阐明了任务的不可拆分性和不可并行性。

1. 数据结构设计是程序设计的中心环节

    数据决定了数据结构，数据结构决定了程序逻辑，也可以说是数据结构的复杂度决定了程序逻辑的复杂度。

2.尽量少画流程图，多用叙述性文字表达

    流程图能够直观的显示出程序运行的逻辑，前提是流程图画的比较细致，否则还是需要文字描述辅助说明。但是绘制详细流程图需要大量的时间，尤其是遇到流程调整时，修改流程图更是耗费时间。笔者就曾经在某个项目开发中，绘制了大量的流程图（多个正常运行流程和多个异常流程的时序图），耗费了将近两天的时间。在后续的实现和调试过程中，优化和修改流程时，经常出现程序逻辑和文档上的时序图不一致的情况，影响了测试人员编写测试用例，增加了开发和测试人员沟通的时间。因此，除了必要的整体架构图和个别正常场景的时序图之外，文档中尽量使用文字描述代替流程图。

    《人月神话》中也提到，有时，很多必要的流程图都是在程序开发好之后根据实现的逻辑补充上去的。笔者也有同样经历：在最终程序完成调试后，再次修订文档中的部分流程图和逻辑。

3. 沟通最重要，可以在早期杜绝接口上的问题

      现代社会的各种工作都是分工合作开发，软件工程也是如此。不同的组件一般由不同的小组或同事开发，组件间按照定义的接口和交互流程协作完成整个软件系统的功能。在实际工作中，经常遇到在系统测试时才发现组件间接口不一致或者交互流程存在缺陷，纠其原因，就是Brooks在《人月神话》中提到的沟通不及时的问题。笔者在工作中，由于前期流通不到位或者未同步到开发文档中，经常导致类似的问题，如接口实现不同（如参数错误）、接口未实现或过度实现、两边理解的交互流程不一致等，导致后续调整和修改耗费了更多的时间，项目进度和质量难以保证。因此，要在早期沟通清楚，在各个问题上达成一致，形成标准文档。在整个开发过程中，遇到问题也要及时沟通确认，不要理所当然的认为应该是这样或那样，保证开发质量。

4. 项目延误时，增派人手可能会适得其反

    Brooks提出上述观点主要基于两个原由：一是新增加的人手需要培训和学习，会增加沟通时间；二是有些任务不是并行的、是不可拆分的。新增加的人手如果不了解项目相关的概念和业务知识时，需要抽出部分原有项目人员对其进行培训，这会耗费一定的时间，而在新手开发过程中遇到问题时，又需要老手抽出时间进行指导。正如Brooks所说，项目的延误主要是源于项目进度安排的不合理导致，出现问题时，最好重新分析项目难度，重新安排项目进度。因此，尽可能不要向落后的项目增加人手，如果非要增加的话，选派那些有经验的、熟悉项目业务知识的人员。

5. 在开发第二个系统时，容易陷入过度设计的麻烦

在开发第二个系统时，因为有了第一个系统的经验，所以会在需求要求的基本功能外，添加很多额外的功能，有些功能可能用户很少会用到。由于这些过度的设计，增加了整个项目开发时间（包括设计、实现、测试、维护），甚至增加整个系统的复杂度和Bug出现的概率，最终延误了产品的上线时间。笔者在工作中，也遇到过过度设计延误项目进度的情形。在当今社会中，时间效率就是市场机会，就是金钱，因此，在设计软件时，要减少不必要的设计，减少项目周期。

6. 软件要由少数人完成结构（架构）设计来确保概念的完整性

    由少数人来完成软件架构设计，这样可以保证各方面的一致性（包括接口定义、交互流程等）

7. 定期重构代码，删除无效的代码

8. 程序、程序产品、程序系统是三个层次上的软件开发。后者需要花费的时间是前者的3倍。程序是可运行的代码

    程序是指可运行的demo,而程序产品是在程序的基础上增加了其它附属的设计实现（接口优化、参数检查、各种测试、文档说明等），是产品级的程序。而程序系统又比程序产品提高了一个级别。因此程序开发可能1小时就能完成，但只能作为内部少数人技术交流使用，如果要达到产品级别，需要花费更多的工作量

9. 进度安排中，1/3时间用于设计，1/6时间用于编码，1/4时间用于单元组件测试，1/4时间用于系统集成测试

    Brooks的观点认为，实现（编码）在整个项目开发中，占用的时间比重是最小的。在软件开发中，架构设计的复杂度决定了编码的工作量，优秀的架构设计使代码逻辑更清晰，所需的代码量更少。笔者在工作中也有同样的体会：复杂的设计会导致混乱的实现，最终使测试工作也陷入麻烦。

在项目安排中，Brooks把一半的时间分配给了测试环节（包括单元组件测试和系统测试），这样分配的理由是：某些设计问题和实现问题，只有经过测试才能发现。此时，如果需要调整设计的话，会耗费更多的时间。因此分配给测试环节的时间实际包含了再设计、再实现的部分，从而保证项目进度。

10. 新人开发新系统，老人维持旧系统

    新、旧系统同时存在时，新系统最终会取代旧系统。旧系统一般相对于新系统会更混乱，更复杂，即Brooks提到的焦油坑。因此旧系统由原有人员进行维护，新人则直接加入新系统，避免陷入旧系统这个焦油坑，会更有助于整个团队的建设和项目的开发。