人月神话有感

Posted 2023-04-20 yzx-sir

读过《人月神话》，马上就被深深的吸引了。 这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到
一些提示。 因此，把感触比较深的几点记下来。

编程会有很多的乐趣 。首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事
物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花上的喜
悦。其次，快乐来自于开发对其他人有用的东西。内心深外，我们期望其他人使用我们的劳动成果，并能对他们有
所帮助，从这个方面，这同小孩用粘十为“爸爸办公室”捏制铅笔盒没有本质的区别。第三是整个过程体现出魔术
般的力量--将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点
唱机所且有的迷人魅力，程序化的计算机毫不逊色。第四是学习的乐趣，来自于这项工作的非重复特性。人们所面
临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物:有时是实践上的，有时是理
论上的，或者兼而有之。最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅 仅
工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质--创造的方式
如此得灵活，如此得易干精炼和重建，如此得容易实现概念上的设想。

软件任务的进度安排的经验法则。1/3计划、1/6编码、1/4软件测试和早期系统测试、1/4系统测试，所有构件已完
成，在许多重要的方面，它与传统的进度安排方法不同， 分配给计划的时间比寻常的多。即便如此，仍不足以产
生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。对所完成代码的调试和测试，投入近一半
的时间，比平常的安排多很多。 容易估计的部分，即编码，仅仅分配了六分之一的时间。 通过对传统项目进度安
排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。
它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证

要保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的
整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发
展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。
需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有
明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东
(模块，功能，算法)，导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。概念的完整性，对
于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住
了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件
系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前
参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具

体实践经验，希望以后能有机会参与比较大的项目。软件系统可能是人类创造中最错综复杂的事物。往往一个很小

的功能，实在也需要开发职员的架构设计方面的完善，对其它模块的影响及扩展，以及代码编写工作。

用户在前台可能看到的只是几个文字，实际是中开发职员昼夜
奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easv，可他们却忽视了很多他们看不到的因
素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。

进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，
我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果
毛里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到
了，也可能一直都找不到;但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许
多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都
会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但
为什么德国妈妈没有这个本事呢?是德国妈妈笨吗?为什么中国妈妈也有找不到的情况?而德国妈妈，虽然速度慢
了点，却始终能够找得到?如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实
验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速
度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗?为什么中国妈妈和德国妈妈会
有这么大的区别?是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗?我觉得是是，你说呢?作者在后
面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。

感触还有很多，以后如果有机会再写。不过，项目成员都是最佳人选很困难，所以第一是处理好人尽其才。

第二是做好项目成员的技能评估工作，根据评估情况和项目技能需求及时组织和安排培训。

读人月神话有感

关于本书，即使很多没读过的人也能说出其中知名度最高的关于人月神话的观点。之前还在知乎上看过有人举了一个例子：一个人生孩子需要十个月，两个人去生孩子同样需要十个月。这一比喻虽不完全恰当，却也大致说出点内容。事实上，作者在书中这样来描述人月神话：软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓（Adding manpower to a late software project makes it later）。关于这点，作者解释的为：向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。同样，作者也向项目管理人员提供了相应的解决方法：

• 重新安排进度。我喜欢P.Fagg，一个具有丰富经验的硬件工程师的忠告：“避免小的偏差（Take no small slips）”。也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
• 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。

　　在三四十年前，作者便以他丰富的项目经验和敏锐的观察力、判断力提出这样创造性的论断，确实令人折服。时至如今，关于人力和时间之间的关系并非呈现线性关系，也不能采用人月作为生产率的衡量标准这一结论已得到普遍的认同。

　　当然，作者的论断以及Brooks准则也并非严格成立：在《20年后的人月神话》一文中，作者给出了Boehm的模型和数据以验证之前的说法太过绝对，但是，“这些细致的研究使“异常简化”的Brooks准则更加实用。作为平衡，我还是坚持这个简单的陈述，作为真理的最佳近似，以及一项经验法则——警告经理们避免对进度落后的项目采取的盲目、本能的修补措施。”

　　许多人都觉得以上观点就是《人月神话》的全部了，并非这样。《人月神话》只是书中一个章节，Brooks准则也只是书中的观点之一。本书所述内容远非于此，它涉及到软件开发与项目管理过程中的方方面面，从开发团队人员配置，到资源的合理配置，到项目文档的撰写以及其他许多内容。实际上，本书取名《人月神话》在某种意义上存在一定的误导性：在《20年后的人月神话》中，作者提炼出了核心观点：概念完整性和结构师。

• 概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。用户所感受到的产品概念完整性是易用性中最重要的因素。
• 结构师。结构师负责产品所有方面的概念完整性，开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益。
• 将体系结构和设计实现、物理实现相分离。为了使结构师的关键任务更加可行，有必要将用户所感知的产品定义——体系结构，与它的实现相分离。体系结构和实现的划分在各个设计任务中形成了清晰的边界，边界两边都有大量的工作。
• 体系结构的递归。对于大型系统，即使所有实现方面的内容都被分离出去，一个人也无法完成所有的体系结构工作。所以，有必要由一位主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。每个部分拥有自己的结构师，他必须就体系结构向主结构师汇报。显然，这个过程可以根据需要重复递归地进行。

　　所以从人个人观点出发，本书用其中一章的标题命名全书，实则不太妥当，哪怕叫做《项目管理规范》都更能做到统筹兼顾（尽管这个名称看起来有点官腔，或者说：土）。当然，作者这样命名，应该有自己的用意（或许用其中一篇作为总标题是这类技术文章合集书籍命名的一种习惯？前段时间看的《黑客与画家》也是这样）。

　　回到书本内容，大部分内容涉及团队与管理，强调了沟通及人的重要性，技术方面虽未过多涉及，却从项目管理的角度高屋建瓴地描绘了软件开发的整个过程，在一些不涉及具体技术的方面（因为年代已经太久远），很有先见性和指导性。

　　简单提下书中对我最有感触的几章吧，其他有些因为经验不够的原因还不能完全理解。

• 第一章 焦油坑 
  　　史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
• 第三章 外科手术队伍 
  　　虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。 
• 第五章 第二个系统效应 
  　　人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。 
• 第六章 沟通顺畅 
  　　架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。 
• 第七章 巴别塔为何失败 
  　　如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。 
• 第九章 袖里乾坤 
  　　最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。
• 第十一章 准备抛弃 
  　　变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。 
• 第十六章 没有银弹――软件工程的必然和偶然 
  　　本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。 　　

　　以上是我对本书内容的简单思考与提炼，以后有一些工作经验后，我还是要回头再看一遍《人月神话》的，把其中不理解的部分继续读透。

　　推荐本文的读者朋友们也去读一读这本书，绝对不会失望的。关于写作风格，看看译者的话：

　　在写作风格上，《人月神话》也足以垂范后世。图灵奖评选委员会曾经特意提到，布鲁克斯不仅为计算机技术做出了杰出的贡献，他也是一位修养全面的学者。《人月神话》并非一份枯燥的技术文献，而是一系列文采斐然的随笔――布鲁克斯对文学和艺术涉猎颇广，他敏锐的思维和渊博的学识，使他在表述软件工程思想时，能从人文和其他工程领域信手拈来旁证博引，深得触类旁通之妙。从英语写作的角度上说，《人月神话》具备随笔体睿智而典雅的风貌，行云流水间文思严谨。读者不必象阅读常见的技术手册一样正襟危坐在工作台前研读，倒是可以在旅途之中，工作之暇轻松地开卷有益，领略精纯的文笔、睿智的思索。 

　　到这，本文差不多该结束了，在此，我想引用《人月神话》的部分结束语，与诸君共勉：

　　我实在无法想像还有哪种生活会比热爱计算机更加激动人心，自从从真空管发展到集成电路以来，计算机技术已经飞速发展。我用来工作的第一台计算机，是从哈佛刚刚出炉的IBM7030 Stretch超级计算机，Stretch在1961到1964年间都是世界上运算速度最快的计算机，一共卖出了9台。而我现在用的计算机，Macintosh Powerbook，不但快，还有大容量内存和大容量硬盘，而且便宜了1000倍（如果按定值美元来算，便宜了5000倍）。我们依次看到了计算机革命，电子计算机革命，小型计算机革命，微型计算机革命，这些技术上的革命每一次都带来了计算机数量上的剧增。

　　在计算机技术进步的同时，计算机相关学科知识也在飞速发展。当我在五十年代刚从学校毕业的时候，我能看完当时所有的期刊和会议报告，掌握所有的潮流动向。而我现在只能对层出不穷的学科分支遗憾地说“再见”，对我所关注的东西也越来越难以全部掌握。兴趣太多，令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊！这个神奇的时代远远没有结束，它依然在飞速发展。更多的乐趣，尽在将来。