《人月神话》和个人的一些想法 - 编程也疯狂 - IT工作生活这点事
现在位置 /
给您更多信息和帮助
在这里您可以找到更多: 技术交流群:
投稿：承接：企业网站门户/微网站/微商城/CMS系统/微信公众号运营/业务咨询
echarts教程系列
[] [] [] [] [] [] [] [] []
本月最热文章
微信扫一扫，徜徉悠嘻网，您的休闲乐园
技术交流群:
专业专注:企业网站门户/微网站/微商城/CMS系统/微信公众号运营/付费问题咨询您所在的位置： &
银弹的希望
银弹的希望
［美］弗雷德里克•布鲁克斯 著UMLChina翻译组 .
清华大学出版社
《人月神话》第十六章论述得是否有一枚银弹，使提高软件的生产率、可靠性和简洁性。本文主要说的是银弹的希望。
银弹的希望
现在，让我们来讨论一下当今可能作为潜在银弹的最先进的技术进步。它们各自针对什么样的问题？它们是属于必要问题，或者依然是解决我们剩下的次要困难？它们是提供了创新，还是仅仅是增量改进？
Ada和其他高级编程语言。近来，最被吹捧的开发进展之一是编程语言Ada，一种20世纪80年代的高级语言。Ada实际上不仅仅反映了语言概念上的突破性进展，而且蕴涵了鼓励现代设计和模块化概念运用的重要特性。由于Ada采用的是抽象数据类型、层次结构的模块化理念，所以Ada理念可能比语言本身更加先进。Ada使用设计来承载需求，作为这一过程的自然产物，它可能过于丰富了。不过，这并不是致命的，因为它的词汇子集可以解决学习问题，硬件的进展能提供更高的MIPS(每秒百万指令集)，减少编译的成本。软件系统结构化的先进理念实际上非常好地利用了MIPS上的进展。20世纪60年代，曾在内存和循环成本上广受谴责的操作系统，如今已被证明是一种能使用某些MIPS和廉价内存的非常优秀的系统。
然而，Ada仍然不是消灭软件生产率怪兽的银弹。毕竟，它只是另一种高级语言，这类语言最大的回报来自出现时的冲击，它通过使用更加抽象的语句来开发，降低了机器的次要复杂度。一旦这些难题被解决，就只剩下非常少的问题了，解决剩余部分的获益必然也要少一些。
我预言，在以后的十年中，当Ada的效率被大家评估认可时，它会产生相当大的变化，但并不是因为任何特别的语言特性，不是由于这些语言特性被合并在一起，也不是因为Ada开发环境会不断发展进步。Ada的最大贡献在于编程人员培训方式的转变，即对开发人员需要进行现代软件设计技术培训。
面向对象编程。软件专业的一些学生坚持面向对象编程是当今若干新潮技术中最富有希望的。[3]我也是其中之一。达特茅斯的Mark Sherman提出，必须仔细地区别两个不同的概念：抽象数据类型和层次化类型，后者也被称为类(class)。抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。抽象数据类型的例子是Ada包(以及私有类型)和Modula的模块。
层次化类型，如Simula-67的类，是允许通用接口的定义可以被后续子类型精化的。这两个概念是互不相干的―― 可以只有层次化，没有数据隐藏；也可能是只有数据隐藏，而没有层次化。两种概念都体现了软件开发领域的进步。
它们的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特性，而不需要表达大量句法上的内容，这些内容并没有添加新的信息。对于抽象数据类型和层次化类型，它们都是解决了高级别的次要困难并允许采用较高层次的表现形式来表达设计。
不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复杂度，上述方法并没有对它有任何的促进。除非我们现在的编程语言中，不必要的低层次类型说明占据了软件产品设计的90％，面向对象编程才能带来数量级上的提高。对面向对象编程这颗“银弹”，我深表怀疑。
人工智能。很多人期望人工智能上的进展可以给软件生产率和质量带来数量级上的增长，[4]但我不这样认为。究其原因，我们必须剖析“人工智能”意味着什么，以及它是如何应用的。
Parnas澄清了术语上的混乱：
现在有两种差异非常大的AI定义被广泛使用。AI-1：使用计算机来解决以前只能通过人类智慧解决的问题。AI-2：使用启发式或基于规则的特定编程技术。在这种方法中，对人类专家进行了研究，判断他们解决方法的启发性思维或者经验法则……程序被设计成以人类解决问题的方式来运作。
第一种定义的意义容易发生变化……今天可能适合AI-1定义的程序，一旦我们了解了它的运行方式，理解了问题，就不再认为它是人工智能……遗憾的是，我无法识别这个领域的特定知识体系……绝大多数工作是针对问题域的，我们需要一些抽象或者创造性来解决上述问题。[5]
我完全同意这种批评意见。语音识别技术与图像识别技术的共同点非常少，它们又都与专家系统中应用的技术不同。例如，我觉得很难去发现图像识别技术能给编程开发实践带来什么样的差异。同样，语音识别也差不多―― 软件开发上的困难是决定说什么，而不是如何说。表达的简化仅仅能提供少量的促进作用。
至于AI-2专家系统技术，应该用专门的章节来讨论。
专家系统。人工智能领域最先进的、被最广范使用的部分，是开发专家系统的技术。很多软件科学家正非常努力地工作着，想把这种技术应用在软件的开发环境中。[6]那么它的概念是什么，前景如何？
专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。推论引擎除了处理推理逻辑以外，通常还包括复杂逻辑或者概率数据和规则。
对于解决相同的问题，这种系统明显比传统的程序算法要先进很多。
●& 推论引擎技术的开发独立于应用程序，因此可以有多种用途。在该引擎上付出较大的力气是很合理的。实际上，这种引擎技术非常先进；
●& 基于应用的、可变更的部分，在基础规则中以一种统一的风格编码，并且为规则基础的开发、更改、测试和文档化提供了若干工具。这实际上对一些应用程序本身的复杂度进行了系统化。
Edward Feigenbaum指出，这种系统的能力不是来自某种前所未有的推导机制，而是来自非常丰富的知识积累基础，这一基础更加精确地反映了现实世界。我认为这种技术提供的最重要进步是具体应用的复杂度与程序本身相分离。如何把它应用在软件开发工作中呢？可以通过很多途径：建议接口规则、制定测试策略、记录各种bug产生的频率和提供优化建议，等等。
例如，考虑一个虚构的测试顾问系统。在最根本的级别，诊断专家系统和飞行员的检查列表很相似，对困难可能的成因提供基本建议。建立基础规则时，可以依据更多的复杂问题征兆报告，从而使这些建议更加精确。可以想象，一种调试辅助程序起初提供的是一般化建议，随着基础规则包括越来越多的系统结构信息，它产生的推测和推荐的测试也越来越准确。这种类型的专家系统可能与传统系统彻底分离，系统中的规则基础可能与相应的软件产品具有相同的层次模块化结构，因此当对产品进行模块化修改时，诊断规则也能相应地进行模块化修改。
产生诊断规则也是在为模块和系统编制测试用例集时必须完成的任务。如果它以一种适当通用的方式来完成，对规则采用一致的结构，拥有一个良好可用的推测引擎，事实上它就可以减少测试用例设计的总体工作量，并帮助整个软件生命周期的维护和修改测试。同样，我们可以推测其他的顾问专家系统―― 可能是它们中的某一些，或者是较简单的系统―― 能够用在软件开发的其他部分。
在较早实现的用于软件开发的专家顾问系统中存在着很多困难。在我们假设的例子中，一个关键的问题是寻找一种简单的方法，能从软件结构的技术说明中，自动或者半自动地产生诊断规则。另外，更加重要也是更加困难的任务是：寻觅能够清晰表达，深刻理解来龙去脉，前因后果事情的自我分析专家；开发有效的技术―― 抽取专家们所了解的知识，把它们精炼成基础规则。这项工作的工作量是知识获取工作量的两倍。构建专家系统的必要前提条件是拥有专家。
专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀的开发者的经验和知识积累为他们提供指导，这是非常大的贡献。最优秀和一般的软件工程实践之间的差距是非常大的，可能比其他工程领域中的差距都要大，一种传播优秀实践的工具特别重要。
“自动”编程。近四十年，人们一直在预言和编写有关“自动编程”的文字，从问题的一段陈述说明自动产生解决问题的程序。现在，仍有一些人期望这样的技术能够成为下一个突破点。[7]
Parnas暗示这是一个用于魔咒的术语，本身的语义是不完整的，并断言：
一句话，自动编程总是成为一种热情，使用现在并不可用的更高级语言编程的热情。[8]
他指出，大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。
可以找到一些例外情况。例如，数据发生器的开发技术就非常实用，并经常地用于排序程序中。一些微积分方程系统也允许直接描述问题。系统评估若干参数，从问题解决方案库中进行选择，生成合适的程序。
这样的应用具有非常良好的特性：
●& 问题通过相对较少的参数迅速地描述特征；
●& 存在很多已知的解决方案，提供了可供选择的库；
●& 在给定问题参数的前提下，大量广泛的分析为选择具体的解决技术提供了清晰的规则。
具有上述简洁属性的系统是一个例外，除此之外很难看到该方法能普及到更广泛的寻常软件系统，甚至难以想象这种突破如何能够进行推广。
图形化编程。在软件工程的博士论文中，一个很受欢迎的主题是图形化或可视化编程，计算机图形在软件设计上的应用。[9]这种方法的推测部分来自VLSI芯片设计的类比，计算机图形化在该设计中扮演了高生产力的角色。部分源于―― 人们将流程图作为一种理想的设计介质，并为构建它们提供了很多功能强大的实用程序―― 这证实了图形化的可行性。
不过，上述方法中至今还没有出现任何令人信服，更不用说令人激动的进步。我确信将来也不会出现。
首先，如同我先前所提出的，流程图是一种非常差劲的软件结构表达方法。[10]实际上，它最好被视为是Burks,von Neumann和Gold stine试图为他们所设计的计算机提供的一种当时迫切需要的高级控制语言。如今的流程图已经变得复杂了，一张图有若干页，有很多连接结点，这种表现形式实在令人同情。流程图已经被证明是完全不必要的设计工具―― 程序员是在开发之后，而不是之前绘制描述程序的流程图。
其次，现在的屏幕非常小，就像素级别，无法同时表现软件图形的所有正式、详细的范围和细节。现在所谓 “类似桌面”的工作站实际上像是“飞机坐舱座椅”。在飞机上任何坐在两个肥胖乘客之间，反复挪动一大兜文件的人都会意识到这中间的差别―― 每次只能看到很少的内容。真正的桌面提供了很多文件的总览，让大家可以随意地使用它们。此外，当人们的创造力一阵阵地涌现时，开发人员大多数都会舍弃工作台，使用空间更为广阔的地板。要使我们面对的工作空间满足软件开发工作的需要，硬件技术必须进一步发展。
更加基本的是，如同我们上面所讨论的，软件非常难以可视化。即使用图形表达出了流程图、变量范围嵌套情况、变量交叉引用、数据流和层次化数据结构等等，也只是表达了某个方面，就像盲人摸象一样。如果我们把很多相关的视图叠加在所产生的图形上，那么很难再抽取出全局的总体视图。对VLSI芯片设计方法的类推是一种误导―― 芯片设计是对两维对象的层次设计，几何特性反映了它的本质特性，而软件系统不是这样。
程序验证。现代编程的许多工作是测试和修复bug。是否有可能出现银弹，能够在系统设计阶段、源代码阶段就消除bug？是否可以在大量工作被投入实现和测试之前，通过采用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性？
我并不认为这里能找到魔法。程序验证的确是很先进的概念，它对安全操作系统内核等这类应用是非常重要的。不过，这项技术并不能保证节约劳动力。验证要求如此多的工作量，最终却只有少量的程序能够真正得到验证。
程序验证并不意味着零缺陷的程序。这里也没有什么魔术，数学验证仍然可能是有错误的。因此，尽管验证可能减少程序测试的工作量，却不能省略程序测试。
更严肃地说，即使完美的程序验证也只能建立满足技术说明的程序。这时，软件工作中最困难的部分已经接近完成，形成了完整和一致的说明。开发程序的一些必要工作实际上已经变成了对技术规格说明进行的测试。
环境和工具。向更好的编程开发环境研究中投入，我们可以期待得到多少回报呢？人的本能反应是首先着手解决高回报的问题：层次化文件系统，统一文件格式以获得一致的编程接口和通用工具等。特定语言的智能化编辑器在现实中还没有得到广泛应用，不过它们最有希望实现的是消除语法错误和简单的语义错误。
开发环境上，现在已经实现的最大成果可能是集成数据库的使用，用来跟踪大量的开发细节，供每个程序员精确地查阅信息，并在整个团队协作开发中保持最新的状态。
显然，这样的工作是非常有价值的，它能带来软件生产率和可靠性方面的一些提高。但是，由于自身的特性，目前它的回报应该很有限。
工作站。随着工作站的处理能力和内存容量的稳固和快速提高，我们能期望在软件领域取得多大的收获呢？有多少MIPS可供自由使用呢？现在的运算速度已经可以完全满足程序编制和文档书写的需要了。编译还需要一些提高，不过一旦机器运算速度提高十倍，程序开发人员的思考活动将成为日常工作的主要活动。实际上，这已经是现在的情况了。
我们当然欢迎更加强大的工作站，但是不能期望有魔术般的提高。
【责任编辑： TEL：（010）】&&&&&&
关于&&&&&&&&的更多文章
开源软件是计算机软件下的一个子类，其中的源代码向公众开放并采
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
讲师： 1人学习过讲师： 3人学习过讲师： 2人学习过
《21天学通C语言（第4版）》是C语言的入门教程，详细
《原油投资宝典》是一本炒原油的实用工具书，从投资者
随着RESTful、云计算、DevOps、持续交付等概念的深入
本书是按照全国计算机技术与软件专业技术资格（水平）考试《软件设计师考试大纲》的要求，参照《软件设计师教程》及近年来考试试
51CTO旗下网站人月神话摘要
我的图书馆
人月神话摘要
关键概念：人月之谜，布鲁斯法则，外科手术团队，设计概念完整性，第二系统效应，沟通，文档，需求理解一致性维基百科，自由的百科全书《人月神话：软件项目管理之道》（：The Mythical Man-Month: Essays on Software Engineering）是由IBM&系统之父所著经典文集，全书讲解、相关课题，被誉为软件领域的，内容源于作者布鲁克斯在公司System/360家族和中的专案管理经验。该书于首次发行（），并于重新发行纪念版（），其中新增了对〈〉一文的评论和回应，与4个额外的新章节。目录&&[]&[][]跟只为私人使用而单独写出来的组件程序（program）相比，做出软件系统产品（programming systems product）所要付出的代价将是九倍以上。估计产品化（productizing）的代价是三倍，若要对组件从事设计、集成、测试，进而凝聚成为一个系统，则代价也是三倍，而且这方面的成本计算基本是独立的。史前时期最骇人的景象，莫过于一群巨兽在焦油坑里做垂死前的挣扎。不妨闭上眼睛想像一下，你看到了一群恐龙、长毛象、剑齿虎正在奋力挣脱焦油的束缚，但越挣扎，焦油就缠得越紧，就算他再强壮、再利害，最后，都难逃灭顶的命运。过去十年间，大型系统的软件开发工作就像是掉进了焦油坑里……——的另一个难题，是从单一到软件系统过程中，所造成度的快速上升，期间并需要包含不同的与，使得软件开发必须面对多样性的。布鲁克斯最早认识到设计程序、开发的差别，他以程序与、的差异，两者之间的不同，并以3×3的复杂度加以说明。[]人月神话（：The mythical man-month）：这部分讲述（man）和（month）并不呈现关系。指出以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的专案追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个专案，而增加额外的沟通消耗。当有 N 个人必须在这群人之中进行沟通时（无阶级关系），当 N 增加，其输出 M 将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。团队交流公式：示例：50 个开发人员，就要&&个沟通管道用“人月”来衡量工作规模的大小是危险的，也是一个容易遭到误解的，使用人月的前提必须是在和可以互换的情况之下：当一份因具有性的限制而不可切分时，就算投入再多的人力，也不会对时程有所影响，生就是需要九个月，你叫多少个一起生都一样，软件工程就是像这样的工作，因为它必须，而除错本身就具有连续性的本质。批注：生孩子的过程和软件开发的过程是不同的，以此来说明人力投入和开发时间无关是不恰当的。首先，两者目标特性不同，孩子是一个不可分割的有机整体，胎儿发育有严格的先后次序，如果有一天科技发达了人体不同器官可以独立发育，然后再合成，那么9个妈妈用一个月生一个孩子理论上是可能的；而软件系统是由不同的子系统组成，各个子系统之间，在逻辑功能上或许存在先后顺序，子系统开发时并没有要求先后顺序，如果非要先后次序开发实现，那是项目管理计划和系统设计不够合理导致的。人月之谜解决的方法之一，软件系统设计要求模块相对独立，模块之间接口明确，多个模块并行开发，是可以通过投入人力加快项目进度的。[]人月（：man-month）指的是“一个要花几个”才能完成软件开发的，通常用来评估一件软件专案的大小。以成本会计（cost accounting）为基础的时程预估技术，使我们误把工作量和专案进度混为一谈，人月是个危险并很容易就遭到误解的迷思（myth），因为它假设人力和工时可以互换。[]在一个时程已经落后的软件专案中增加人手，只会让它更加落后。根据Brooks法则，增加人员到一个已经延误的专案里，等于是火上加油。除非你可以把工作区分，让新进人员可在不影响他人工作的状况下有所贡献。把工作切分给更多人做将造成额外的沟通（communication）代价——训练和相互的交流（intercommunication）。欲增加软件专案的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。批注：为了防止进度落后时，增加人手导致沟通和训练成本上升等问题，需要做几项预防措施；项目计划尽可能考虑到各种风险，项目启动时需要安排备份人员，适度参与概要设计和详细设计评审，代码review活动，以熟悉项目，在进度落后时，已投入项目尽快投入工作。[]在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在上也最不完整。本“以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在上也最不完整。”内容自相。&请在讨论问题所在及加以改善。以一位首席程序员为主、类似于团队的提供了一个良方，既可因少数人的决策而兼顾到产品的整体性，又可因多数人的合作与大幅沟通减少而得到全部人的。[]在系统设计时，保有概念整体性（conceptual integrity）是最重要的原则。功能概念复杂度比（这个比值是为了量测使用便利性，对简单和困难的运用都很有效）才是系统设计的最终测试标准。功能多，不见得是好事。要达成概念整体性，设计必须出自于一个人的想法，或是极少数人的一致决定。对大型软件专案（小专案也一样）来说，将架构设计独立于实现之外是取得概念整体性强而有利的方法。如果系统必须保有概念上的整体性，那么就必须有人来控制这些概念，这就是需要的原因，无庸置疑。许多、实现、实现的工作都是可以同时进行的。（不论硬件或软件设计，都可以同时进行）[]第二系统效应（：The second-system effect）就一个人所做过的而言，第二个系统是最的系统，一般来说，都倾向于过度。当他做第三或之后的系统时，之前的会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部份。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟目前专案的基本系统假设有冲突而不再适用，OS/360有好多这样的例子。（则似乎是1990年代的示例）对大部份的设计人员来说，它也是个第二系统，设计成员分别来自操作系统、Stretch、Project Mercury实时系统、给7090用的IBSYS操作系统等等，几乎没有人拥有两个上述系统的发展经验，所以OS/360可称得上是一个最佳的第二系统效应示例。[][][][]手册或书面规格是不可或缺的，虽然光靠它是不够的。手册载明的是的（external）规格，用来描述并制定出用户从外观上将或看到的所有细节，撰写手册便是架构设计师的主要工作。当用户和实现人员的反应不断地显示出设计上难以使用或实现之处，手册就会堕入重新准备、修改的之中。为了造福实现人员，将修改的程度予以（quantize）是很重要的——在时程上应该要有载明的信息。[][]失败的软件专案经常发生在开发者与用户间对认知的误解。开发者抱怨用户说不清楚需求，而用户抱怨开发者误解他们的意思。布鲁克斯认为“最困难的单一项目，是地决定要什么。”[]初版20周年纪念版[]增修内容：将中所主张的所有论断整理出一个简洁的，包括了原书的主要理念：就配置的比例而言，大型所面临的是跟小型专案完全不同的问题，这引申出产品的概念整体性是其中的关键，而达成概念整体性虽然困难，但却是可能办到的。作者对他当初所提出的这些论断，在经过一个世代之后所做的观察。转载布鲁克斯1986年发表于IEEE《Computer》的经典论文〈〉。布鲁克斯对于他1986年的论断“十年内不会有任何银弹”所做的回应。[][]Frederick P. Brooks, Jr.; 译者：钱一一.&. 经济新潮社. 2004年&.&&&（正体中文）.[][]
TA的最新馆藏[转]&[转]&你觉得《人月神话》是讲什么的 | Geek笑点低小组 | 果壳网 科技有意思
1111887人加入此小组
后羿和嫦娥的爱情故事后羿和吴刚的激情故事人类移居月球的科幻故事
+ 加入我的果篮
应该和《没有银弹》一起看！讲的是狼人，吸血鬼，还有赏金猎人的故事。
(C)2017果壳网&&&&京ICP证100430号&&&&京网文[-239号&&&&新出发京零字东150005号&&&&
违法和不良信息举报邮箱：&&&&举报电话：