读 《人月神话》 有感

《人月神话》由著名计算机科学家Frederick P. Brooks, Jr.于上世纪70年代所著，是对软件工程实践经验的总结与案例分析。书中的许多观点和建议至今仍具有重要的学习价值。

初次听说这本书实际上是在23年的后半年，当时看到一个同校的b站up主在他的一期视频中推荐了这本书，受书名吸引我点开了视频。在听了讲解后，我这才了解到所谓“人月”的概念——原来是一种以多少人花费多少月来计量工作量的方式。而这一方式又是极度危险的，它隐含了人员与时间的相互替代性，实际上“如果1人干10个月如果等同10人干1个月，那就成神话”，这也是《人月神话》这本书想要表达的核心观点之一。当时的我只觉得这本书仅限于上层管理人员阅读，不如新技术更加吸引人，因而那时并没有“安利”到我。但最近又在老师的推荐下，细细品读了一番，不得不感叹经典总归是经典。

（其实这篇也是课程作业，所以文风比较拘谨orz）

我们的困境

书中开篇提出了一个形象的比喻：

过去几十年的大型系统开发就像是一个焦油坑，许多大型和强壮的动物在其中剧烈挣扎。

焦油坑是软件开发过程中困境的象征。表面上看我们拥有足够的能力去解决每一个单独的问题，但是一旦一切联系起来，我们常常会感叹问题的复杂程度，犹如线团一般缠绕，各种因素交叉在一起，这样的难题在团队合作中是不少见的。而编程本身也是一件创造性的活动，同样能够带来乐趣，我想这应该也是很多人喜欢编程的一个原因。自然，我们不希望自身陷入这样的焦油坑，坏了兴致。书中带我们一步步了解所谓焦油坑是何物，以及如何摆脱这样的困境。

项目的加速不是靠“堆数值”

Brooks法则指出：

投入更多的人来开发一个紧急的项目只会让进度更慢。更多并不意味着更好，有些事最好由一个人来完成。

我们从事编程这项活动往往不是“孤独”的，不管是企业项目开发，开源项目合作，还是在学校中结组完成一个课题。那么就有一个问题——是不是人越多，开发的项目就越好，进度就越快呢？这两个答案都是否定的。就如书中一直秉持的一个观念，人员数量和时间从来不是可以等效换算的概念，新成员的加入通常还要学习相关的知识，了解当前项目的情况，同时人员数量的增加与沟通成本的增加是分不开的。在大二一年有了不少合作开发的经历之后，对此深感理解。

就拿之前我参与的一个微信小程序项目开发举例，项目最初由两个人开发，考虑到项目开发时限以及后续维护问题，负责人临时决定我们二人再去拉两个人进来。大家的第一想法自然是可以减轻自身负担的话，那能有什么别的意见呢。但是后来发现我们在增加人数之后，需要开会为其讲解目前的项目内容（这里也有一个文档匮乏的问题），在进行开发的过程中，也要重新考虑任务分配问题，以及当任务有交集之后，新人常会遇到一些不确定的事情，还要针对不同模块询问对应的人来解惑。实际上效率并没有按照相应的比例增加，甚至可以说在某些时候比原来二人开发的方式还要慢。试想如果是企业级开发，动辄几十几百乃至几千人，倘若没有一套合理的管理机制以及推进项目的稳定方案，又将面临多大的难题？所以，我们要重新审视效率的影响因素，去窥探软件工程更本质的要求。

警惕你的第二个系统

第二系统效应表述如下：

就一个人所做过的设计而言，第二个系统是最危险的系统，通常倾向于过度设计。

书中的例子应该是特指操作系统了，实际上不管我们设计开发什么项目，总会受先前的经验所影响，一方面以往的开发经验的确能够让我们在之后的设计实现上有前车之鉴，不至于走远走偏，但另一方面，我们也容易陷入过分的自信陷阱。特别是开发第二个系统时，我们时常会建立在第一个系统开发积累的经验下去设计，这时我们并不清楚哪些是必要，哪些是不必要，这时就会有过度设计的风险。

好消息是，我们在更之后的系统设计中，便可以通过先前多次的开发对比系统之间的差异，来帮助我们识别不够通用的部分。我们的关注点就落在了“开发第二个系统”这个最需要警惕的阶段，书中提到我们可以有意识地避开，我想我们在追求心目中的理想模式时，也要先推敲一下是否符合当前项目的基本系统假设。

交流与协作

这本书既然是讲人与团队关系的，那么就绕不开交流协作的问题。正如上文中也提及到的，项目的开发并不是各管各的，很多时候我们并没有办法找到一个完美的划分任务的方案，换言之，要想协作，人员之间的交流沟通是不可避免的。

这也是我长期苦恼的一个地方。书中不止一个章节提到了概念完整性与设计一致性的意义。由于我之前也当过一些项目的负责人，很能体会到这种不一致带来的问题。这通常都指向一个问题——团队内没有一个统一的规范。或许我们每个人都有足够的能力去完成一个比较复杂的项目，但当我们合作之后，并没有1+1>2的效果。我们并不在乎对方的风格、想法是什么样的，只关心交付给自己的任务，这当然也没什么可以指责的地方。但这时负责将整个项目统一起来的人就要受难了。我常常因为这个问题，花费了大量的时间在修改统一其他人的代码上。明明是相似的模块，但两个人各凭己见，虽然都如期完成了，但后期维护的难度明显增大了。甚至更糟糕的时候，一个人做的部分几乎需要完全推翻重做，才能适配上除他之外的人做的部分，耗费了大量的人力和时间成本。缺少交流的合作看起来像是不按配对规则搭起来的积木塔，摇摇欲坠。

那我们应该如何有效交流来获取一致性？建立文档当然是一个很好的方案。我们在软件工程基础课上，需求工程课上，以及其他一些需要合作的实训中，充分认识了文档的作用。但实际情况却很可悲，除了要求需要有文档的课程项目外，我们几乎没有一个项目会遵循这种“死板”的方案。而在那些需要文档的项目，我们又都草率完成，还发现实际开发变数太多，常常没有按照文档中的内容做，也就是文档的作用被虚化掉了，被当成了独立于编码之外的“其他任务”。好的文档应该是能够帮我们理清思路并且统一规范的，而非一种负担。所以我想，在彻底解决我们对文档不够重视这一问题之前，优先要考虑的是如何提升自己编写文档的能力。

定期开展会议也是十分重要的。目前参与的校外游戏开发项目，我们是每周定期开一次线上会议汇报当周完成进度，来确保互相之间了解各自工作情况，避免重复开发，同时也能让负责人时刻把握进度；周内不定期开小组会议（像程序组、美术组这样的），来解决临时的一些问题和计划的提前声明。我认为这样的方式非常有效。以往项目开发小组的人数不多，我习惯采用互相交流而不开统一会议的方式来节省时间，但人数一多，任务一复杂，这样的会议必不可少。

告别进度灾难

千里之堤，溃于蚁穴。

一谈起这个就难免想起自己因为不善于进度管理而导致的一次次项目延期。最可怕的灾难不是突如其来的变故，而是悄无声息的侵蚀。每日积累的进度落后是难以识别、不易防范且难以弥补的。这样的进度问题往往是里程碑定义不准确以及执行不彻底导致的。我们在制定计划时，常常会用到一些模糊的用词，并且没有一套确定的验收标准。有的时候可能事情确实完成了，但是没有完全符合预期的效果，那么势必会在之后的日程中进行整改，而我们的计划显然没有将这个不确定因素考虑进去，就导致本应结束的任务没有正常结束，持续不断地影响后续的进度。

因而，有一套明确可执行的计划规范是很重要。不过估计时间成本来选定时间节点也是个技术活，它往往依赖过去的项目开发经验。书中提到的PERT图在我们的软件工程基础课上也有学习过，这确实是一个定量进行项目管理规划的好方案，但是也确实如其他方法一样，我们必须要有按照规矩做事的自觉，这些方案才能发挥其应有的作用，否则怕是徒有其表。

回看人与工程

我们总说计算机科学与技术和软件工程是有本质区别的专业，软件工程这一概念的最初提出也不是为了解决某一个或某一些计算机难题。软件工程究竟是什么？我认为重点在于“工程”。同其他“xx工程”一样，我们要将软件开发视作工程建设，而非单纯的求解问题，所以必须要了解工程化的方法，必须要从以往的工程实践中去总结经验，将管理手段与技术方法相结合，我觉得这本身也是一种艺术。人作为其中的活跃因素，自然也是需要分析的关键内容。《人月神话》就是这样一本总结以往管理经验，指明问题，给出方案的书，探讨了面对复杂工程时，团队应何去何从的问题。虽然书中个别观点囿于时代因素略显过时，但整本书的价值时至今日仍然不减，依然是软件工程领域值得一读的好书。

书中很多内容在有足够的实践经验后会有更深的理解，或许在未来参加了工作，再次回看这本书，又会有不一样的体验。