读人月神话有感

标签：期刊   发表   若是   产品   sys   目的   卖出   分解   错误   

关于本书，即使很多没读过的人也能说出其中知名度最高的关于人月神话的观点。之前还在知乎上看过有人举了一个例子：一个人生孩子需要十个月，两个人去生孩子同样需要十个月。这一比喻虽不完全恰当，却也大致说出点内容。事实上，作者在书中这样来描述人月神话：软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓（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倍）。我们依次看到了计算机革命，电子计算机革命，小型计算机革命，微型计算机革命，这些技术上的革命每一次都带来了计算机数量上的剧增。

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

读人月神话有感

标签：期刊   发表   若是   产品   sys   目的   卖出   分解   错误   

原文地址：https://www.cnblogs.com/yang-qiu/p/10421707.html