人月神话-11章未雨绸缪

试验性工厂和增大规模

  开发一个更灵巧或者更好的系统。系统的丢试图和重新设计可以一步完成,也可以一块块地实现。

  为舍弃而计划,无论如何,你一定要这样做。

唯一不变的就是变化本身

  目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现在好得多。不但目标上的变化不可避免,而面设计策略和技术上的变化也不可避免。

为变更设计系统

  细致的模块化、可扩展的函数、精确完整的模块间接口设计和完备的文档。

  变更的阶段化是一种必要的技术。每个产品都应该有数字版本号,每个版本都应该有自己的日程表和冻结日期,在此之后的变更属于下一个版本的范畴。

为变更计划组织 架构

  当系统发生变化时,管理结构也需要进行调整。

  管理人员需要参与技术课程,高级技术人才需要进行管理培训。项目、进展和管理问题必须在高级人员整体中得到共享。

  只要能力允许,高层人员必须时刻做好技术和情感上的准备,或者队亲自参与开发工作。其工作量很大,但很值得。

前进两步,后退一步

  程序维护中的一个基本问题是:缺陷修复总会以固定(20%~50%)的几率引入新的bug,所以,整个过程是前进两步,后退一步。

  作为引入新bug的一个后果,程序每语句的维护需要的系统测试比其它编程要多。理论上,在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。实际情况中,回归测试必须接近上述理想善,所以它的成本非常高。

前进一步,后退一步

  Lehman和Belady发现模块总数量随版本号的增加呈线性增长,但是受到模块数量随版本号的增加呈指数增长。所有修改都倾向于破坏系统 的架构,增加了系统的混乱程度(熵)。

 

时间: 2024-10-29 19:10:13

人月神话-11章未雨绸缪的相关文章

人月神话札记:未雨绸缪

前言:软件在设计阶段如果能够多考虑一些后续的维护工作,显然是非常棒的.然而对于现阶段的我,或者很多程序员来说,未雨绸缪有很大难度,我们往往即使已经下雨了,也依然无法把窗户关紧,那么如果你想得到一些指导的话,请随我来,看看我能否品出一些味道来. 没有什么是永恒的,除了变化. 普遍的做法是,选择一个方案,试试看:如果失败了,没关系,再试试别的.不管怎么样,重要的是去尝试. 我觉得书中提供的这两个观点非常的棒,首先,任何事都不可能一成不变,敏捷宣言也提倡我们要拥抱变化.其次,在解决问题的时候,就是要不

人月神话-13章整体部分

剔除Bug的设计 细致的功能定义.仔细的规格说明.规范化的功能描述说明以及这些方法的实施,大大减少了系统中必须查找的bug数量. 测试规格说明 自上而下的设计. 结构化编程 构件单元调试 系统集成调试 使用经过调试的构件单元 搭建充分的测试平台 控制变更 一次添加一个构件 阶段(量子)化.定期变更

人月神话第一章焦油坑

职业的乐趣: 不断学习的乐趣 创建事物的乐趣 开发对他人有用的东西 在易于驾驭的介质上,进行开发 职业的苦恼: 将做事的方式往完美的方向调整. 往小的说:1.依赖其他人的代码 2. 当产品终于出来时,已经过时了. 程序距离编程系统铲平还有很长的一段距离.

01人月神话阅读笔记

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

《人月神话》读书笔记之第1章焦油坑

开始看到焦油坑时,不知道这个是什么意思,这和编程系统有什么关系呢?看完第一章大概明白要表达的意思.焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底.IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意. 通过编程系统的演进可以看到简单的程序已经不能称作为系统,编程系统+编程产品才构成了编程系统产品,编程系统产品的复杂度将是一般程序的9倍.只有编程系统产品才是真正有用的产品,是大多数系统开发的目标.

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

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

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

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

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

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

《人月神话》读后感----一到三章

<人月神话>这本书是我们老师推荐给我们的,同时老师还推荐给我们另一本书<梦断代码>.由于时间的原因,我只能先选一本书来读. 这本书里面的好多观点,对于今天的软件工程依然适用.如"没有银弹"这个观点,说明了作者对于软件工程独到的见解.身为一名软件工程的学生,我应当仔细读完关于 软件工程的任何一本书.并将观点与想法运用到实际之中. 作者在第一章中说到,过去几十年大型系统的开发就像焦油坑一样,虽然各种各样的团队通过努力开发出可运行的系统,但是只有少数的项目可以开发出满