《人月神话》阅读体会(三)

终于读完了这本《人月神话》,对后面的章节中印象最深刻的部分还是祸起萧墙和银弹章节。

“项目怎么会被延迟了整整一年的时间……延迟的时间是一天天积累下来的”。通常灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。项目进度就是这样,经常以一种难以察觉,但是残酷无情的方式慢慢落后。一天一天的进度落后是难以识别、不容易防范和难以弥补的。每件事的变化可能只会将某项活动延迟半天或者一天,但是整个进度开始落后了,尽管每次只有一点点。所以一定不要去忽视那些细节。正所谓细节决定成败。

日常生活中我们总是说某某某已经“90%完成”了,调试在大多时候也都是“99%完成”的,反正就差一步了嘛。可是具体的里程碑是百分之百的事件。“结构师和实现人员签字认可的规格说明”,“100%源代码编制完成,“测试通过了所有的测试用例”。这才叫百分之百,这才叫真真正正地完成。而我们不论是编程还是日常生活常常会栽的跟头就是由于差不多思想,什么什么反正差不太多,差不太多是差多少,是差的太少,还是差的太多,就是这样,常常使我们离成功只有一步之遥,这一步说简单只有一步而已,说难,它比前面的任意99步都要难跨过去,所以不到最后决不能说下完成的结论。

没有银弹-软件工程中的根本和次要问题。我们一直在寻找着银弹,然而我们必须明白在软件开发的过程中,只有适度改进,没有包治百病的银弹。在软件开发的过程中,重要的不是采用了什么工具,而是不论用何种工具,都要达到项目本身的客户需求。任何方法论之前,先要探求问题的来源,否则,对各种方法论的依赖或滥用,有害无益。

作者认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。当然,我们还是会犯一些语法错误,但是和绝大多数系统中的概念错误相比,它们是微不足道的。而概念的完整性也是本书的核心观点。歌德说过,“不了解,就无法真正拥有”。以后再编程序之前,一定要先对自己的设计思路有一个清晰完整的概念,而不是盲目下手,想哪儿编哪儿。

软件是不可见的和无法可视化的。 其中的秘密就是逐步发育成长,而不是一次性搭建。软件开发是一件棘手的事情,并不会有魔术般的解决方案,现在是从业者研究和分析革命性进展的时刻,而不是等待或希望它的出现。现在有可能可以在软件生产率上取得逐步的进展,而不是等待不可能到来的大突破。所以,新时代的我们要抓紧时间奋斗起来,随时准备迎接未来的挑战,共同推进软件开发的进步。

这本书整体对于目前的我还有一点很深的感悟是,对于像我这样未涉世的大学生,往往会将关注点只放在编程,放在技术层面,而很少关注类似于软件工程方法论的东西。造成这种原因有一些奉技术第一思想的影响,和自己的经验太少,使得注意力旁移。技术与方法论两者之间会有自己的平衡,无法给出二者之间的排序,可以确定的一点是,某一方面的占比过高,必定会引来灾难。所以这警示我在学习技术的同时也要学习一些方法论,提高自己的一种编程素养。而这本书,不是讲“鱼”的书,而是讲“渔”的书,通过读它,我学习到了软件工程的思维方式,以及项目经理的视角下看问题的方式。

最后引用书上的一句话作为结尾。“这个神奇的时代还远远没有结束,他依然在飞速发展,更多乐趣,尽在将来”!

原文地址:https://www.cnblogs.com/zzstdruan1707-4/p/10376536.html

时间: 2024-10-13 21:05:04

《人月神话》阅读体会(三)的相关文章

人月神话阅读笔记—第三章

人月神话阅读笔记-第三章 一个由一流人才组成的小型的精干的队伍比由一群平庸的程序员组成的大型团队更有效率,但是这里面有一个重要的问题:如何在有意义的进度安排内创建大型的系统. 优秀的程序员和较差的程序员之间生产效率的差距是巨大的,当一个10人的精干团队进行开发,和一个100个人的平庸程序员进行开发,前者的效率更高.但是对于效率和概念的完成性来说,最好由少数干练人员开发,而大型系统需要大量人员进行开发,但是这两者是有矛盾的,需要进行平衡. 在开发过程中,可以使用一种崭新的开发方案,类似于外科医生做

人月神话阅读笔记—第四章

人月神话阅读笔记-第四章 ------2016.6.14 概念的完整性是很重要的,为了反应一系列连贯的设计思路,可以省略一些不规则的特性和改进,不提倡独立和无法整合的系统,最需要的是在整体概念上的完整性要求. 获得概念的完整性时,会出现一种情况,编程系统使计算机更加好用,但是功能比较多的时候,软件外部描述就会比系统本身大很多:但是功能太少,不能满足需求,但是都需要满足概念上的完整性. 在进行概念的完整性时,产品设计需要由一个人或者少数几个人来实现,但是对于大型的系统,需要将设计方法.体系结构的工

人月神话阅读笔记03

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

人月神话阅读笔记07

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

人月神话阅读笔记之一

人月神话讲的主要是软件工程方面的,如何配置人力进行开发 .虽然对于软件编程我们对其了解并不多,但是对于在软件功能的实现,程序设计人员面临的客观性的困难至少我可以站在略懂的角度上去理解他们,对于一个或多个项目来说,公司大多都会搞人海战术,进度没有提前,还整天加班,最后用户不满意,开发人员整天郁闷,结果是用户对公司失去了信任,成了一槌子买卖,开发人员旧人一一辞职,新人天天引进,做法没有改变,情况没有改观,公司没有发展,这就是问题.人月之所以不能成为神话,正是因为增加人手的同时也增加了人与人之间的交流

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

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

人月神话读后感(三)

作为软件工程的经典著作,<人月神话>的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解. 其中内容就是: (1)提倡外科手术式的团队组织: 在软件开发组织上的过份民主,往往带来的是没有效率和责任,参与其中的人想法太多,层面参差不齐.所以,软件开发的组织,应该借鉴外科手术式的团队方式,有一个主要的负责人,其他人都是分工协作的副手,这样效率最好,结果最好.(2)软件项目的核心概念要由很少的人来完成,以保证 概念的完整性: 少就是多,项目的定位需要和功能多少的权衡.太多的想法,使项目没有焦

01人月神话阅读笔记

内容源于作者Brooks在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验.<人月神话>探索了达成一致性的困难和解决的方法,并探讨了软件工程管理的其他方面. "焦油坑"这章,作者把大型系统开发比作一个"焦油坑".作者从开发系统产品引入先分析职业的乐趣与苦恼,得出"编程,一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动."这一结论. "人月神话"这章,指出缺乏合理的时间进度是

人月神话阅读笔记01

Brooks法则:向进度落后的项目中增加人手,只会使进度更加落后. 我们刚刚接触软件编程,对于在软件功能的实现.程序设计人员面临的困难我也能略微理解了.项目的时间依赖于顺序上的限制,人员的最大数量依赖于独立子任务的数量.对于一个或多个项目说,有这样一个运作规律:以前公司大多会采取人海战术,但进度没有提前,反而整天加班,最后用户不满意,开发人员整天郁闷,结果是用户对公司失去了信任.开发人员呢,旧人一一辞职,新人几乎天天引进,但做法并没有改变,情况也没有好转,公司自然没有发展. 人月之所以不能成为神

人月神话阅读笔记05

软件项目的进展并不能用简单的线性关系抽象.软件开发不是一项简单重复的体力劳动.设想如果一个人要搬东西,假设他一个人需要一个小时搬完,但是如果他再找来5个人一起搬,可能只需要十分钟.软件开发比这要复杂的多:如果一个人用十天能做完的一个项目,他做到第五天后想找人来一起做,这就不是找五个人一天就能做完的事情.也许完成项目花费的时间比十天还要多.他要花时间为新加入的队员介绍项目,为他们合理分工,如果有一人没按时完成,所有人都要停下等待--由此引出一系列不可预估的问题.复杂度大大提高.总之:从项目的人数和