人月神话之没有银弹

读《人月神话》也有了一段时间了,现在也理清了一些自己的思路了,这次主要是针对里面的《没有银弹》这一话题,提出自己的看法。

我认为,在现有的所有体系中,都没有所谓的“银弹”,“银弹”只是人们想拥有一个一劳永逸的解决办法而针对一个具体事件想出来的临时的可行的某一个措施,它的效用时间是有限的,并且解决方法本身并不是一成不变的,而是随着时间与经历的增长在变化的。

用哲学的观点来看,运动是永恒的,我们不能将问题的处理定格于某一时刻或者某一阶段或者某一特定问题的问题处理。软件工程也是变化的,就好像当我们拥有了瀑布模型外,发现它并不能满足我们一些特定的需求,又出现了增量模型、螺旋迭代模型、敏捷开发等新的模型,且还在持续的更新中。从这个角度来看,我们永远没有办法采用一个已知的问题解决模式处理最新的问题。这个就如同我国在发展社会主义的时候不能照搬苏联模式,只能自己去根据国家实情去探索新的道路,新的发展方法。

这些变化都是因为人们的需求发生了变化而产生的,然而人们的需求不会满足,这就决定了软件需要时刻的变化,也决定了有银弹的希望不大。计算机硬件上人们采用微电子器件、晶体管、大规模集成带来了生产力的数量级增长,这看似已经是银弹了,但是这并不是所谓的“银弹”,不是以后所有的硬件生产就是这样进行流水线生产就能解决一定问题了,硬件生产技术一定会发生变革更新的。如果这样的流水线生产硬件设施就是“银弹”的话,那么现在的软件生产应该也算的上了吧,比起最初的命令行,现在拥有的丰富的编程库以及部分的图形化编辑界面,软件的生产量不知道已经是原来的多少倍了。

当然,不可否认上面的那些先进技术给软件的发展带来了巨大的福音,但是这也是在发展过程中,我们所知道的一种解决问题的有效技术、手段,它将会在以后的某一时刻被淘汰掉。说到底,现在的软件、硬件以及其他的大部分技术,都是人们在社会的生产生活中所使用的工具,当它们的发展与社会生产力不匹配的时候,它们终将被淘汰。

所以,“银弹”并不实际存在,存在的只是人们的一种期望,一种解决某一特定问题的短时间内有用的技术或者说手段。

时间: 2024-11-25 13:02:48

人月神话之没有银弹的相关文章

第三次读书笔记-人月神话

<人月神话>读书笔记 <人月神话>这本书几年前就听别人说是本很经典的软件开发方面的书,被赞为"神品".这本书的成功之处在于他思想的前卫性,以至于不只是软件行业的人在读,在印度甚至人手一本. 这本书主要是针对软件开发管理方面的内容,这主要原因可能是因为作者以前就是项目的管理者,他是站在管理者的角度写的.即便这样,对于一个从来没有参与过真实项目开发,更没有领导过团队的我还是有一定的吸引力,这本书中我最喜欢的就是焦油坑.人月神话和没有银弹这三章.这本书里面为了论证某一

人月神话03

这两周我把<人月神话>剩下的章节看完了. “整体部分”这章讲了 我们的构思是有缺陷的,因此总会有bug.但我们可以利用一些方法来减少bug的出现,细致的功能定义.详细的规格说明.规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug 数量. 构件的单元测试,单元测试这一概念在这学期学习软件工程课时老师经常提到,作者很有先见性,测试对于发影藏的bug起着很大作用. “祸起萧墙”,本章讲了软件开发的不可与预测性.对计划和控制职能进行适度的技术人力投资是非常值得赞赏的.它对项目的贡

人月神话感想

人月神话感想 在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了. 在软件领域, <人月神话>具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书. 首先,让我印象深刻的是<人月神话>提出的两条著名的法则: 1.人月神话:向一个已经延后的项目中投入更多的人力资源只会让它更延后. 人月神话看上去这么浪漫的名字,原来并不是真的说神话故事,作

读《人月神话》之感受

中国科学技术大学软件      朱秀秀           原创作品转载请注明出处 自暑假以来,就认识到这本书几乎成了软件行业不可或缺的一碗鸡汤,不过在我刚一看到“神话”两个字,两眼顿时放光,觉得闲暇之余还可以看看神话之类的小说,煞是惬意,可是暑假档期排得实在是不能再满了,于是乎,决定开学之后再看吧. 暑假的课程紧锣密鼓的进行着,一天,两天....只能说从来没有如此充实的度过长达一个月的起早贪黑的学习生活,好在这段难忘的时间终究还是离我而去,几场考试过后,向往已久的研究生生活开始了. 于是在老师

《人月神话》读书笔记 第3篇

<人月神话>读书笔记 第3篇 第15章:另一面 第16章:没有银弹 第17章:再论“没有银弹” 第18章:<人月神话>:是与非? 阅读<人月神话>马上就要接近尾声了,发现后面讲的内容越来越专业,但是对于我们正在进行的团队合作启发很大.前几天老师在课堂上给他们看了他统计整理的个人与每个团队第一个冲刺阶段的进度表格,看到有些严格按照要求每天有进度,有些则相反,也可能是完成了但是没有及时汇报进程.那“项目怎么会被延迟了?……延迟的时间是一天一天积累下来的.”目前我们做的都是一

读《人月神话》有感

<人月神话>是IBM360系统之父布鲁克斯所著的经典,它为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践,读后受益匪浅,倍受启发. 本书分为15节,其中焦油坑,人月神话,外科手术队伍,贵族专制,民主政治和系统设计以及没有银弹是我最喜欢的几章,以下是我从这几个章节所获得的知识和见解:从(焦油坑)一节中,我认识到了 编程系统产品开发的工作量是供个人使用的.独立开发的构件程序的九倍:编程行业也存在一些苦恼:(1) 将做事方式调整到追求完美,是学习编程的最困难部

人月神话有感

初见书名时还在奇怪为什么老师要我们看一本这书,在我刚刚见到这本书时我以为说的是人类登上月球的书籍,后来明白了本书的名字并不是人类和月球之间的神话故事,而是软件工程的一些迷思,人月是一个人一个月的人力单位. 在这本书里作者提出软件工程中各个项目的比例应该如下: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand 初始时心中还在迷惑为什么编程的

《人月神话》和个人的一些想法

用了5,6个小时把这本提升逼格的书看完了,收获还是挺大的... 重要名词和主要观点解释 1.焦油坑:形容软件开发的困难和挣扎.软件项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,一个一个淹没在焦油坑中. 2.人月神话:人力和时间不是平衡的线性关系,用人力作为生存率的衡量标准是一个神话.缺乏合理的进度安排是造成项目滞后的最主要原因 3.没有银弹:10年内没有任何编程技巧能给软件生存率带来数量级的提高. 软件开发中困难的部分是规格说明.设计和测试这些概念上的结构,

人月神话读书笔记

作者介绍:20世纪最后一年也就是1999年的图灵奖,授予了年已69岁的资深计算机科学家布鲁克斯(Frederick Phillips Brooks, Jr.).布鲁克斯这个名字在中国知之者不多,但在美国却是大名鼎鼎.因为他在60年代初只有29岁时就主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作,取得辉煌成功,从而名噪一时.以后他作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上,在计算机技术的诸多领域中都做出了巨大的贡献.从某种意义上说,对于布鲁