人月神话-读

<人月神话>是软件工程方面的一本经典著作,作者布鲁克斯(Frederick P. Brooks)被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理.由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖.Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师.1999年,他还荣获美国计算机领域最高奖图灵奖. 1.增量式开发.书中特别建议这种开发模式,这种开发模式最大的

最好的团队组成应该是类似外科手术队伍结构,这样我们能够获得减少沟通,提交生产效率等等诸多好处,而且最重要的是我们将获得概念的完整性. 将设计交由一个人或者非常少数忽悠默契的人来完成才能保证概念的完整性,而将体系结构,设计实现和物理实现相分离则是获得概念完整性的强有力方法,这一点契合了我们现在已经作为常识的“关注点分离”理念. 在本话题的相关章节中最让笔者印象深刻的是作者在第四章开篇序言中就以建筑业举例——建筑大师需要 首尾融会贯通其前辈建筑师的成果 同时完全掌握他们那个时代的建筑技术 最后还要能

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

<人月神话> 读书心得: 因为现在还是学生,且没有什么真正在应用项目的开发经验,所以读<人月神话>这本书,与其说是在学习这位计算机先驱的经验,不如说是在了解一个大型软件系统的开发过程以及在开发过程中将会遇到的困难.但是,通过一些小项目的练习经验,还是有很多感触. 如果以后工作了,从事软件编程这个行业,在拿起这本书读一读,有了实际的经历,一定会有更多的收获. 读<人月神话>所感,布布扣,bubuko.com

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

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

在平时的工作中,时常体会到消耗大量时间的往往不是一些难度很高的技术问题,而是一些由于工作流程管理不当及沟通不善造成的时间浪费,比如没有经过深入全面地分析和详细地设计就开始编码,事后常常要花大量的时间返工和修改:比如代码管理混乱,合并代码时常常出现各种小错误,耽误了进度:比如没有撰写清晰完备的文档,后续其他同事在维护之前的代码时,非常费时费力,等等.因此,学习一些项目管理方面的知识非常有必要.抱着这种心态,我翻开了<人月神话>,开始第一次阅读.下面摘录一些本次阅读过程中的一些笔记: 1.任何创造

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

人月神话书如其名一样震撼人心,它引起了许多别的领域的读者对此进行评价. 律师,医生,社会学家,心里学家,和软件人员一样对此书提出评论和建议.人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点,后者在 20 年内至少翻了 1000 倍.正像第 16 章所解释的,反常的并不是软件发展得太慢,而是计算机硬件技术以一种与人类历史不相配的方式爆发出来.很多年后作者还是会被道“你现在认为哪些在当时就 是错误的?哪些是现在才过时的?哪些是软件工程领域中新近出现的?”很多年来人们对软件生产率和影