人月神话这本书好

几乎是计算机软件开发的发展历史
一些坑,前人早遇到过
说,增加项目人手,不能提高开发速度。忽略了成员的沟通成本,培训成员的成本,拆解任务后,就变了,结果项目还是继续延长

一些不能拆解的任务,就不能靠增加人加快速度

生小孩,需要12个月,增加多少个人都一样,需要12个月

做项目,任务的评估时间忽视了软件开发的特点,我们往往凭着直觉来评估周期。增加人手不能解决问题。

煎一个鸡蛋,需要10分钟。可以加快到2分钟,把火力调大,但是鸡蛋就烧糊了

这些例子都是书里面的,看了有同感

很讨厌那种说这个很简单,他自己去做,被一个小bug栽跟头可能卡住很久

不过这本书里面提到一个经验,调试和测试的时间花费是最多的。比开发写代码要多得多
现在看来是这样,有时候为一个bug,调试,定位问题,耗费长时间。

以后我们做时间预估的时候,就不要凭着自己想当然
我们自己做的时候,不会这样。等到位置变了,就想当然了

的确是屁股决定脑袋

时间: 2024-10-10 00:03:38

人月神话这本书好的相关文章

读“人月神话”有感

在软件工程这门课中我们学到,一个软件的开发过程不是简单的一个选择编程语言编码实现的过程,而是一个要经过可行性研究分析.需求分析.形式化说明.总体设计.详细设计再到编码实现的过程,后期还需要对软件进行维护,整个软件的开发过程需要开发成员之间的密切而有效的合作. 这个学期,经同学的推荐,我读了一下<人月神话>这本书,一开始并不知道这是一本关于软件工程的书,毕竟这书名迷惑性太大,一般的人都会理解为是人跟月亮的神话,完全不会像软件工程的方向靠近.不过当你读了这本书之后会发现,整本书都是在以一种非常幽默

人月神话感想

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

人月神话读书笔记

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

人月神话阅读笔记—序言及第一、二章

初读人月神话这本书的前言和序言,觉得这本书在关于软件体系结构思想层次方面应该是很高的,而且它流传甚广,并且经过了40余年的沉淀,仍然经久不衰,可见此书的影响是相当深远的. 从目录来看,此书说的不是如何进行程序代码的编写,更多的是关于软件工程中的管理问题,从很多的具体事例,和软件工程历史上发生的一些著名事件来引出章节的内容,以及通过这些具体事件,反映了一些什么样的问题和解决的办法. 第一章的标题名为焦油坑,以开发过程中遇到的很多问题来比喻.介绍了编程系统产品所耗费的时间其实是很多的,接着介绍了作为

《人月神话》读后感之一

昨天开始了阅读人月神话这本书,首先这名字-><人月神话>,一开始没搞懂 这个名字到底啥意思,关于软件工程的书扯到了人与月?直到我开始一页一页的阅 读这本书,人与月作为衡量一项工作的规模是一个危险和带有欺骗性的神话. 它暗 示着人员数量和时间是可以相互替换的.人月神话,是因为时间精力的消耗与独立 投入的人力.时间不成线性相关,所以每一次的项目估算和调整都需要谨慎为之, 可以说做项目可能就是在尖刀上走路,处处危机. 这本书第一章节叫焦油坑,这一章节开头说“史前史中,没有别的场景比巨兽 在焦油

读&lt;&lt;人月神话&gt;&gt;

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职

《人月神话》读后感

这个学期选择软件冲程这门课我受益匪浅.在这段学习的过程中读完了一本人月神话则是我认为最有价值的经理. 在软件领域中,很少能有像<人月神话>一样具有深远影响力和畅销不衰的著作.作者布鲁克斯被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理.由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖.Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师.1999年,他还荣获

人月神话——我的理解

人月神话中第一章就提到了The Tar Pit ,在焦油坑种挣扎并且体验快乐并苦恼的编程过程,人月神话的开始就在讨论超级项目的合作与分工的矛盾以及内部模块的复杂交织.作者是IBM OS/360项目的项目经理和主要负责人,IBM/360所犯的错误以及给我们的启示成就了这本书,本书的目的是为身处焦油坑里的软件工作人员提供一点帮助和引导.依作者的观点,“人月神话”的出现和工程进度的不合理安排有很大关系,因此合理工程化体系的建立很有必要,盲目的软件生产心理和人员协调中存在的问题导致了软件工业的巨大失败率

人月神话读后感

书中应用焦油坑表示过去几十年的大型系统开发,很多大型和强壮的动物在其中剧烈挣扎.让我感觉到,软件开发过程中所遇到困难是多么的多,开发多么艰难.但是这本书同时告诉了我们软件的开发有苦也有乐,我们可以在编程过程中体会那份快乐.<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关