人月神话笔记

人月神话笔记

  • 1975 出版的经典书籍, 记录其中令我印象深刻且到目前也不过时的内容

人月神话

  • 人月是危险和带有欺骗性的神话,因为它暗示人员数量时间是可以相互替换的

  • 向进度落后的项目增加人手只会导致项目更加落后

    • 任务重新分配本身和所造成的工作中断
    • 培训新人员
    • 额外的相互沟通
  • 关于进度安排, 1/3计划、1/6编码、1/4构件测试以及1/4系统测试

外科手术队伍

  • 把大型团队拆分为若干个类似于外科手术式的小团队
    • 每个小团队有一名主程序员(类似于主刀医生),所有的问题分解和功能定义都通过主程序员来完成,以此来降低沟通成本
    • 每个主程序员配备若干个平庸的人帮他/她打下手

贵族专制、民主政治和系统设计

  • 概念完整性是系统设计中最重要的考虑因素

    • 为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成
  • 将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法

蛇添足, 贯彻执行, 为什么巴比伦塔会失败?

  • 不要过度设计,尤其是在第二个系统(第一个系统完成后开发的第二个系统)中,不要过度自信,保持警觉,避免初始的概念和目标得到充分的体现,而不让一些次要的功能喧宾夺主
  • 沟通交流的重要性, 尽早交流, 持续沟通

整体部分

  • 在设计系统结构时精心设计,减少各个部分间的耦合,各个模块的独立性越高,系统级的 bug 的可能性就越低

未雨绸缪

  • 目标上(和开发策略上)的一些正常变化无可避免,事先为它们做准备总比假设它们不会出现要好得多
  • 机器在变化,配置在变化,用户的需求在变化,所以现实系统不可能永远可用。崭新的、对于原有系统的重新设计是完全必要的。

祸起萧墙

  • 里程碑的选择只有一个原则,那就是,里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义

  • 减少角色的冲突。老板必须规范自己,不对项目经理可以解决的问题做出反应

没有银弹

  • 不可能有某种技术突破(银弹)能够彻底解决“根本性困难”,从而导致软件开发效率有数量级的提高

  • 增量开发,把软件当做是生长的有机体, 从简单的核心开始,一边交付一边开发,不断增加新的功能,一边增加新的功能,一边重构已有的部分