读人如读书阅读答案，读人的教育心得体会

?

小brooks的《人月神话》这本书在软件工程管理领域畅销40年，我看的是40周年中文纪念版。相比于原版增加了一些作者根据今天软件工程管理现状添加的一些新的观点与评论，看看哪些过时了，哪些依然有效。另外还附录了一些名人以及读者对本书的评论。整体来说，本书的主线——人月神话、没有银弹在现今的软件工程管理领域依然属于有效的基础理论。但是，其中一些方法论对于国内的软件项目管理的环境是不适应的，对于这些方法论我们可以吸收其思想精髓，改造其具体方法，创造一些中国特色的软件项目管理方法。这是一个很大的话题，我经验尚浅，所以本文就先不谈这个。我想谈的是本书中对我映像比较深的几个概念理论。焦油坑 焦油坑是作者用来形容大型系统开发的一个概念。史前时代，恐龙、猛犸象、剑齿虎这些大型食肉动物碰到焦油坑也是没有办法挣脱的，而且越用力就越容易被沉入坑底。这种场景就像极了大型系统开发的工作。

各种团队，大型的或小型的，庞杂的或精干的，一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队行动就会变得越来越慢。对于问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。

基本上一个大型的编程系统产品的开发成本会是单个的简单程序的9倍。这里的编程系统产品是指的由很多编程程序以及系统组合而成的可交互、协作的程序集合。我们每个人都应清晰的认识到这样一种非线性关系，认识到真正的大型编程系统产品并不是简单程序的简单堆叠。这也就是所谓的“焦油坑”。既然是明知是焦油坑，那我们为什么要跳进去呢？作者在书中分别列出了开发大型系统产品的乐趣以及苦恼。对我来说，在软件开发中我的乐趣在于： 开发对其他人有用的东西的乐趣。面对不重复的任务，不断学习的乐趣。最大的苦恼在于： 产品在完成前总面临着陈旧过时的威胁；只有实际需要时，才会用到最新的设想。人月神话 对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果，这一方面是因为所有的编程人员都是乐观主义者，我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug”，另一方面则来源于市场的压力，这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情愿的，对于创造性工作来说，创造者常常是在实现过程中，才发现在构思设计时候的不完整性和不一致性，从而反馈到的构思设计上，处理这种问题的时间和复杂程度会随着项目的结构以及任务的大小而呈现非线性增加的关系。所以对于大型软件项目来说，“一切都将运作良好”就是一件概率非常小的事情了。在软件项目中我们往往用人月这个指标在衡量项目的工作量。但是人月这个指标实际上是一个危险的带有欺骗性的神话。它暗示着人员数量和时间是可以互相替换的。只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。在实际软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为软件开发本质上是一活动：慈云数据爆款香港服务器，CTG+CN2高速带宽、快速稳定、平均延迟10+ms 速度快，免备案，每月仅需19元！！ 点击查看项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。简单来说就是，3个人要干3个月的事情不是说安排9个人就能1个月干完了。而且，在进度落后的项目中增加人手的做法，往往只会使进度更加落后。这就是去除了神话色彩的人月。

项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。从这两个数值可以推算出进度表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度安排。总之，在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要的原因，它比其他所有因素加起来的影响还要大。

外科手术队伍 面对软件项目的“焦油坑”以及“人月神话”，作者给出的一个解决办法是——“外科手术队伍”。有研究表明，同样有两年经验而且受到同样培训的情况下，优秀的专业程序员的生产率是较差程序员的10倍。在软件项目中，一个小型的、精干的队伍是最好的，这样既减少了沟通成本，又提高了生产率。但是对于真正意义上的大型系统来说，小型精干的队伍往往意味着太慢。这就是矛盾的所在，对于效率和概念的完整性来说，最好由少数精干的人员来设计和开发，而对于大型系统来说，则需要大量的人手，以使产品能在时间是满足市场的需求。在软件项目中的“外科手术队伍”有一个类似于外科医生的首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制主架构源代码，测试以及书写技术文档。首席程序员还拥有一个副手，他主要作用是作为设计的思考者、讨论者和评估人员。与传统的两人队伍每人负责一部分工作的设计和实现不同，“外科手术队伍”中的这两个人需要一起了解所有的设计和全部的代码。其他的程序员以及管理者，文档编辑人员等围绕着主架构的设计来具体实现功能以及推进项目。这种队伍的好处就在于既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。作者特别强调软件系统的概念完整性，为了确保这种完整性也是需要由一个首席程序员或者具有共识的小型团队来从上至下的对系统结构进行设计。

要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。

没有银弹

在未来的十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度地提高软件的生产率、可靠性和简洁性。

人狼这种民间传说中存在的怪物，会在月圆之夜由我们熟悉的人类面孔变成可怕的狼脸。我们熟悉的软件项目也有着人狼的特性，看似简单明了的外表，但是却可能随时变成一个进度落后、超出预算、存在大量缺陷的怪物。在民间传说中对付人狼唯一可靠的武器就是银弹。所以银弹在软件项目中就是比喻这种使得软件成本像计算机硬件成本一样迅速降低的尚方宝剑。然而，作者在40年前悲观的告诉我们，没有银弹。40年后我们回首望去，这个预言恐怕是真的。首先我们要认识到的是软件开发中存在着两种困难，一种是根本的——软件特性中固有的困难，另一种是次要的——目前存在的，但并非与生俱来的困难。对于前一种困难来说，没有银弹。而后一种困难可以通过软件工程管理或者技术的进步来克服。

软件开发中困难的部分是规格说明、设计和测试这些概念上的结构，而不是对概念进行表达和对现实逼真程度进行验证。

在软件开发中存在着4个天生的根本困难——复杂度、一致性、可变性和不可见性。 复杂度是说在规模上，软件实体可能比以往人类创造的其他任何实体都更加复杂。一方面，来自于计算机本身的复杂性，还有软件系统的状态的繁多。另一方面，软件系统的各种元素还是以非线性递增的方式在交互，使得软件复杂度比非线性增长还多得多。而且由于复杂度，软件团队成员的沟通成本也非常的大，也产生了一系列的技术上的困难，同时还会引发很多管理上的问题。一致性说得其实是软件兼容性，我们开发的软件往往为了保持一些必须遵循的人为惯例和系统，必须为这些接口保持其一致性。只要是从事软件行业的人应该都能体会到软件的可变性，因为应用、用户习惯、自然社会规律、计算机硬件等的各种变化都会无情地持续地强迫着软件也要随之变化。在软件行业中有一句话就是，唯一不变的可能就是变化的需求。不可见性是说软件在客观存在上不具有空间的形体特征，无法可视化。无论是流程图还是时序图等等软件工程中使用的图表都无法像地图或者电路图一样在整体上给予所有使用者完整的概念。从而使得软件设计人员和开发人员之间在设计上的一些概念无法完整而清晰的进行沟通交流。现代软件工程中通过高级语言、分时系统、面向对象程序设计、使用开源库、敏捷开发等新的理论实践不断在克服软件开发中的次要困难，同时也减轻了一些根本困难。但始终不能消除软件复杂度这样的根本性困难。因为随着软件工具能力不断的提升，软件开发中需要面对的复杂度其实也是在不断提升的。所以，我们在软件生产效率上的提升需要的是逐步的进步，而不是期待一个一蹴而就的突破。最后

软件工程的焦油坑在将来很长一段时间内会继续使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的活在刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的工程管理方法的最佳应用；良好的自我判断以及能够使我们认识到自己的不足——上帝所赐予的谦卑。

95840848

《读人如读书阅读答案，读人的教育心得体会》来自互联网同行内容，若有侵权，请联系我们删除！