读书笔记《Mythical Man-Month》

前面的话

Every bullet has its billet.

简介

  • 书名:人月神话 Mythical Man-Month
  • 作者:小弗雷德里克·布鲁克斯
  • ISBN:9787302392644

他只是坐在那里,嘴里说:“做这个!做那个!”当然什么也不会发生,光说不做是没有用的 —-哈里·杜鲁门,论《总统的权力》

笔记

  • 人和时间的互换仅仅适合可以分解,且不需要进行交流的工作中,比如小麦收割,系统编程中近乎不可能

  • 很多创造性活动,依托于现实的物理介质。比如建房子。这些物理介质往往会限制了思路的表达。也同样带来了很多意料之外的困难。我们总是使用主观主义色彩去责怪这些介质。然而编程而言,介质极其容易被掌握,可以表示十分纯粹的思维活动,我们期待于不会碰到困难,导致了乐观主义的弥漫。

  • 如果项目需要进行一对一的交流,那么工作量的递增可以想想为多边形的边数,呈 n(n-1)/2 这种形式递增。三个人的工作量是两个人的三倍。

  • 软件进度的经验法则:

    • 1/3 计划
    • 1/6 编码
    • 1/4 构件测试和早期系统测试
    • 1/4 系统测试,(所有构构件已完成)

    除了系统测试,进度基本可以保证。一定为系统测试安排足够时间

  • 总之在众多的软件项目中,缺乏合理的进度安排是造成项目滞后的主要原因。

  • 他们喜欢一流水平小团队而不是几百人的大型团队。

  • 2000$ 每年的程序员的生产力是 1000$ 的程序员的十倍以上

  • OS/360 这个操作系统的巅峰的时候曾有100人在为之工作。从 1963 到 1966 将近 5000 个人年。进行人月置换的话,那么 200 人的团队需要 25 年的时间才能达到产品现有的水平。

  • 大型项目的每个部分都应该由一个团队解决,类似与外科手术。而不是蜂拥而上的方法。

  • 概念上的完整性,

    • 设计师的贵族专制,压制平民编程人员?
    • 设计书的指定无法实现,或者代价太高,人们陷入困境
    • 保证技术细节被理解,被精准的整合到产品中?
  • 易用性是产品的目标,那么功能和复杂度的比值才是系统最终的测试标准。


不一定只有结构师才会有好的创意,新的概念经常来自于实现人员或者用户。系统的概念完整性决定了其使用的容易程度。不能和系统基本概念进行整合的良好想法和特色,最好放在一边不予考虑。对呀重要但不兼容的思想,需要进行重新的整合设计。


对于产品之中的的贵族专制制度,对于结构师而言是肯定的,因为他们的工作产物的生命周期比那些实现人员的产物要长,并且一直处于子解决用户问题,实现用户利益的核心地位。未为了得到系统概念上的完整性,必须要有人来控制这些概念,所以呢这是一种无需任何歉意的贵族专制制度


在开发第二个相同产品的时候,(文中是系统),很有可能出现画蛇添足的现象。普遍现象是过度设计第二个系统,加入很多之前第一个产品被放在次要位置的想法。这时候是最危险的,因为产品的差异性,使得很多经验得不到验证。


文中一直提到一个很失败的例子,就是 OS/360 的其中 26 字节的常驻日期翻转例程来正确的处理闰年的 12月31日问题 ,其实这个完全是可以交给操作员来完成的工作。这里就是典型的对于功能过多的考虑。也存在对某些技术过度细化精炼的趋势。由于基本的设想已经发生了改变,所以很有可能技术已经显得明显的落后。成为了最后的也是最优秀的恐龙


形式化定义,需要超出自然语言的精准,古老的格言说:不要携带两个时钟出海,带一个,或者三个。这样才可能方便的定下何为标准,或者谁为标准。


一次添加一个构件,阶段(量子)化,定期变更。

巴比伦塔为什么失败

巴比伦塔的失败,在圣经里面写的很有意思,上帝看了人类建造的城市和高塔。说:他们是一个种族,使用一种语言,现在建造高楼,以后就没有什么可以拦住他们了。来我们在他们的语言里面制造一些混淆这样他们之间不能互相听懂。这样,上帝把人们分散到世界各地,于是他们不得不停止建造那座城市。

《创世纪》中记载,巴比伦塔是人类继诺亚方舟之后的第二大的工程壮举,同时,也是一个彻头彻尾的失败工程。从先决条件分析:清晰的目标?人力?材料?足够的时间?足够的技术?
对于前面的先决条件的回答的答案都是肯定的。那么所缺乏的,存在于两个方面:交流交流的结果————组织

他们无法交流,从而无法合作,当合作无法进行的时候,工作便陷入了停顿。史书中记载,交流缺乏导致了争霸,沮丧和集体猜疑很快的部落开始分裂,大家选择了孤立。

当项目有N个工作人员的时候就出现了 (n^2-n)/2 个交流接口,有接近 2n 个必须合作的潜在团队。团队组织的目的,是为了减少所需的交流和合作数量。这种方法就叫做 人力划分

树状编程队伍,在每个团队里面需要的是:

  • 任务 a mission
  • 产品负责人 a producer
  • 技术主管或者结构师 a technical director or architect
  • 进度 a schedule
  • 人力的划分 a division of labor
  • 各部分之间的接口定义 interface definitions among the parts

对于小型的团队的结构,应该是 技术主管作为总指挥,产品责任人充当其左右手。在小型团队是最适合的,对于大型团队,产品负责人作品为管理者更加的合适。

没有银弹

No Silver Bullet,人们为了消灭狼人的方法,需要寻找银色的子弹。没有什么方法可以在短时间内实现生产效率的数量级的提升
把开发过程分成 根本的(essence)————软件特性中固有的困难次要的(accident)————出现在目前生产中的但并非与身俱来的困难

我认为软件开发中困难的部分是规格说明,设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼真程度进行验证。

增量开发————增长,而非搭建系统,首先系统应该能够运行,即使未完成任何有用的功能,只能正确调用一系列的伪子系统。接着系统一点点的被充实,子系统轮流被开发。

我现在还记得,在1958 年,当听到一个朋友提及搭建(building)而不是编写(writing)系统时,我所受到的震撼。


实际上指的是 :软件开发过程中的固有的概念复杂性,无论时任何时间,使用任何方法设计和实现软件的功能,他都存在

在所有被误导的科学探索中,最悲惨的莫过于对一种能够将一般金属变成金子的物质, 即点金石的研究。这个由统治者不断地投入金钱,被一代代的研究者不懈追求的、炼金术中 至高无上的法宝,是一种从理想化想象和普遍假设中——以为事情会像我们所认为的那样— —提取出的精华。它是人类纯粹信仰的体现,人们花费了大量的时间和精力来认可和接受这 个无法解决的问题。即使被证明是不存在,那种寻找出路和希望能一劳永逸的愿望,依然十 分的强烈。而我们中的绝大多数总是很同情这些明知不可为而为之的人,因此它们总是得以 延续。所以,将圆形变方的论文被发表,恢复脱发的洗液被研制和出售,提高软件生产率的 方法被提出并成功地推销。

我们太过倾向于遵循我们自己的乐观主义(或者是发掘我们出资人的乐观主义)。我们 太喜欢忽视真理的声音,而去听从万灵药贩卖者的诱惑 。

金句

  1. 系统编程的进度安排背后的第一个错误的假设是:一切都将运行良好,每一项任务仅花费它“应该”花费的时间
  2. 使用人月作为一项工程的规模是一个危险和带有欺骗性的神话
  3. 《创造者的思想》:创造性的活动分为三个阶段:构思,实现,和交流
  4. 任务不能被分解的时候,人手的添加对进度没有任何的帮助,比如孕育生命的十个月。
  5. Brooks法则:向进度落后的项目添加人手,只会使得进度更加落后。
  6. 这些研究表明,效率高和效率低的实施者之间的个体差异非常搭,经常能够达到数量级的水平
  7. 一拥而上的开发方法是高成本的,速度缓慢的,低效的,开发出的是无法在概念上进行集成的产品。
  8. 没有规矩,不成方圆。最差的建筑,往往是那些预算远远超过起始目标的项目。
  9. 创造性活动包括三个独立阶段:体系结构(architecture)设计实现(implementation)物理实现(realization)。他们往往可以并发进行。
  10. 我可以召唤地下的幽魂。这我也会,什么人都会,可是当您召唤他们的时候,他们会应召而来吗?
  11. 在未来的十年内,无论是在技术还是管理方法上,都看不出有任何突破性的进步,内阁爆炸在十年内大幅度的提高软件的生产率,可靠性,和简洁性。
  12. 构建软件最可能彻底解决方案是不开发任何软件。

二十年后

留下点什么吧