《人月神话》读后感

前言

本人在做软件开发以来，一直对开发当中的种种现象保持疑惑，程序员与项目之间需要保持一个怎样的关系才能获得美妙的平衡？敏捷开发中所倡导的两周一个迭代，增量开发极限编程是如何演变而来的？
这些名词上的困惑一直伴随着我，经过最初的疑惑后也忘了去深究，直到读到《人月神话》这本1975年写的老书，原来道理在其中已经说的很清楚，1975年就有人分析了软件开发过程中存在的问题，并给与了一些建议和预言，有些预言甚至在今天都仍然有效。
 

焦油坑

一个能用的简单工具程序，一个程序员独立开发一两天就可以完成。但一个成熟的软件产品，拥有上百个功能和复杂交互的系统产品所需要的开发时间可不是一百个简单工具程序开发时间累加起来就能完成的。这是焦油坑陷阱，软件的复杂度足以令经验丰富的程序员焦头烂额。
增量开发、自上而下开发就是基于这样的背景被发明出来的。
 

人月神话

人月神话是指：缺乏合理的时间进度是造成项目滞后的主要原因，向滞后的项目增加人手只会令进度更加落后。
其实我刚做开发时也认为项目进度落后时，通过增加人手是可以赶上原先进度的。可当我工作两年后再回头看这问题，的确，确实如Brooks所说，向滞后的项目增加人手并不会有多大的气色。
为什么？因为一个新人进入团队是需要花时间培训以及熟络的，不可能进人一进项目就能参与开发，如果真是一进项目就参与开发那肯定在开发过程中会有很多问题咨询老员工增加额外的沟通时间成本，而且代码质量往往不尽如人意，后期维护相当麻烦，总的来说加人并不会对进度有多大的改善反而会增加项目的成本。
如何解决项目落后的问题？打个比喻，软件开发就像生小孩需要十月怀胎，项目是有他最小颗粒度的，在明显人手不足的情况下加人的确可以加快进度，但项目中每个人做的事已经足够具体和细腻的话，加人只会使项目更加落后。
所以需要合理的估算时间进度，对进度保有时间的余力，因为编程是纯粹的思维活动，总会有出乎意料的bug出现，破坏原先乐观的进度计划。

外科手术队伍

经验丰富的程序员可以比较差程序员的开发效率高10倍，因此我们在软件开发中需要向外科手术队伍一样，有一位主刀医生、一位副主刀医生、以及其他各司其职的医生和护士。
这句话怎么理解？因为想要获得软件整体性的协调统一，就必须有人控制这些概念，Brooks称这类人叫必须存在的专制贵族统治，他们就是首席程序员，放在当下也可以称之为架构师。
架构师类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底的减少沟通的工作量。这的确是个很棒的主意，太过于民主的确不利于产品的统一性。

画蛇添足

牢记开发人员承担创造性的实现责任；结构师只能提出建议，同事需要听取开发人员在体系结构上改进的建议。
这句话我的理解是分工明确，各自做各自职责范围内的事，不越界，在开发前大家先约定好各自需要做的分内的事，并给予对方充分的信任。

为什么巴比伦塔会失败

巴比伦塔项目失败是因为缺乏交流以及交流的结果——组织。
团队之间应该尽可能多的方式交流，无论是正式交流（邮件往来）还是非正式地进行简要技术陈述的常规项目会议，项目人员之间的交流可以有效地减少因沟通导致的BUG。所以让一个团队的成员坐在一起办公是非常好的主意。

提纲文档

在文件的一片汪洋中，少数文档成为了关键的枢纽，每个项目管理工作都围绕着它们运转。它们是经理们的主要个人工具。
关键文档很重要，目标、原型图、流程图、进度、预算、组织机构图、工作空间分配。有了这些关键性的文档，项目经理可以自信地开展工作，项目在大的方向上就会有一个明确的方向。

未雨绸缪

系统的丢弃和重新设计可以一步完成，也可以一块块地实现，但这是必须完成的步骤，系统熵随时间增加。
软件开发随着版本不断的迭代，复杂度会呈几何式的爆发，bug会越来越多，越来越难以维护，这时候软件就像个定时炸弹随时会给大家一个惊喜！
我们需要走两步退一步，怎么理解这句话？在项目开发了两到三个版本后就应该停下来，优化重构代码，将这两三个版本迭代下来冗余的代码精简抽象，使其更具拓展性，这是十分有必要的。
很多项目因为工期等各种各样的原因没有办法优化重构，随着版本的不断迭代，代码越来越臃肿复杂，最后就成为了屎山，打开代码就会有捏着鼻子跑开的冲动，因为屎山代码无论是阅读性、可维护性都太差了，改都不敢改。
当项目维护了很长一段时间后，比如5年，就应该考虑重新开发一个新项目了，使用当下新的技术栈、按照当前的需求重新设计数据库数据结构，这样重新设计的项目性能会足够的好，结构清晰，方便拓展，整个项目都会焕发新的活力。