人月神话03

这两周我把《人月神话》剩下的章节看完了。

“整体部分”这章讲了 我们的构思是有缺陷的,因此总会有bug。但我们可以利用一些方法来减少bug的出现,细致的功能定义、详细的规格说明、规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug 数量。 构件的单元测试,单元测试这一概念在这学期学习软件工程课时老师经常提到,作者很有先见性,测试对于发影藏的bug起着很大作用。

“祸起萧墙”,本章讲了软件开发的不可与预测性。对计划和控制职能进行适度的技术人力投资是非常值得赞赏的。它对项目的贡献方式和直接开发软件产品有很大的不同。计划和控制小组作为监督人员,明白地指出了不易察觉的延迟,并强调关键的因素。他们是早期预警系统,防止项目以一次一天的方式落后一年。软件项目一旦偏离,需要考虑的因素很多。

“另外一面”,作者预见性的认为“自文档化”方法的基本思想可以得到大规模的应用。““自文档化”方法”对空间和格式要求更为严格,这一点的应用可能会受限;而命名和结构化声明显然可以利用起来,在这方面,宏可以起到很大的帮助;另外,段落注释的广泛使用在任何语言中都是一个很棒的实践。而现代软件工程开发中各种文档起着很重要的作用。

“没有银弹-软件工程中的根本和次要问题”,所有软件活动包括:根本任务——打造由抽象软件实体构成的复杂概念结构。次要任务——使用编程语言表达这些抽象实体,在空间和时间限制内将它们映射成机器语言。软件任务中的必要活动,也就是那些和构造异常复杂的抽象概念结构有关的部分:  仔细地进行市场调研,避免开发已上市的产品。 在获取和制订软件需求时,将快速原型开发作为迭代计划的一部分。有机地更新软件,随着系统的运行、使用和测试,逐渐添加越来越多的功能。 不断挑选和培养杰出的概念设计人员。针对概念上根本问题的颇具前途的方法:购买和自行开发。构建软件最可能的彻底解决方案是不开发任何软件;需求精炼和快速原型;增量开发——增长,而非搭建系统;卓越的设计人员,是那些激动人心、拥有广大热情爱好者的产品往往是一个或者少数伟大设计师们的思想。

再论“没有银弹”,作者列举出了当时一些非常先进的技术或思想理念,例如ada和其他高级编程语言、面向对象编程、人工智能、专家系统、"自动"编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率,但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了,纵观现在的软件开发领域,虽然新技术层出不穷,但是还是没有一种银弹能够让软件开发产生一次革命。

《人月神话》的观点:是与非,总结了先前的知识点。

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

《人月神话》探索了达成一致性的困难和解决的方法,并探讨了软件工程管理的其他方面。在《人月神话》中,既有很多发人深省的观点,又有大量软件工程的实践,为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰,保持产品本身的概念完整性是一个至关重要的需求。

以我现在的水平还不能完全读明白人月神话,希望以后抽时间多读几遍,细读几遍。

时间: 2024-08-01 22:47:27

人月神话03的相关文章

人月神话阅读笔记03

阅读了<人月神话>第10章 提纲掣领,里面提到的关于软件相关的开发文档的问题,使我受益颇深.以前每每写程序时,老师总会要求我们写一些需求分析,软件流程图,还有各种各样的日志文档,心里总是觉得烦不胜烦.明明程序已经写好了,文档写不写又有什么关系呢?这不是在浪费时间嘛.但是后来在写四则运算的编程题时,我就遇到了一些麻烦.刚开始我自己写又进行“翻新”的时候,我总是忘了自己之前是怎么想的,思路是怎么样的,很多时候不得不花上许多时间去重新阅读上次的代码,或者直接推翻重写.后来进行二人开发时,发现没有文档

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

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

《人月神话》读后感

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

人月神话阅读笔记07

第1章 焦油坑      焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底.IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意.项目四要素,人员,组织环境,干系人,外部依赖和约束,风险和假设,团队,人等诸多问题都是你必须要考虑的问题,任何一个要素出现大的差错都可能导致项目失败,只有所有要素能够平衡好,团队能够协调一致才能够保证项目成功 第2章 人月神话      进度问题是IT项目管理最为关注的

人月神话——我的理解

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

《人月神话》阅读笔记02

今天我读了人月神话—外科手术队伍和巴比伦塔的失败.有许多体会. 在开发小组中,最好和最查人员生产率比在10:1,在运行效率和空间上5:1惊人差距.如果一个200人的项目中,有25个最能干和最有开发经验的项目经理,那么开除剩下的175名程序员,让项目经理来编程开发. 对于一个软件项目,适合的项目团队规模在20人左右,这是一个专职的IT项目经理可以管理的最大值.那由于项目进度压力需要增加团队规模到100人的时候,让项目经理来开发实际操作是很困难的方式,在这里推荐的方式是将系统按照高内聚,松耦合分解为

人月神话读后感

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

《人月神话》读书笔记之开篇

最近半年尝试带一个小团队,开发一款新产品.写了两年多的代码,现在突然转换了一个角色,面临更多的挑战.现在开始搜集产品用户场景,编写用户和系统需求文档,制定工作计划,安排人员工作,制定目标,跟踪项目成员工作进展. 在这个过程中遇到种种问题,如何建设团队,如何评估工作量,安排人员和时间,如何下发工作,如何跟踪进展,如何识别风险,如何推进项目等. 因为是新产品,公司从稳定安全方面考虑,开始只给了两个应届生,后面陆续给了1一个老员工和3个实习生.我们是一个全新人的团队,我担当的项目负责人和技术决策人两个

也说《人月神话》

 温馨提示:文章的内容与引子无关.       时值深秋,校园里的银杏树, 美的醉人, 一片片优雅的飘落,宛如蝴蝶的狂欢! 图书室中,书籍满架,透出大学那种特有的庄重与浪漫. 图书室里的人一如从前一样, 不多不少, 总是有些人走了, 又有一些人来了. 变化的只是管理图书室的阿姨,双鬓添霜. 我走进一个书架, 挑出了一本最旧的书, 虽然页面泛黄,页脚脱落, 仍然不失“王者”般的威严. 因为书名实在迷人---<人月神话> 某爱慕 小恪的漂亮女生: 小恪, 你在看什么? 这是什么书? 24K纯屌丝小