#每日一书#

8.20 人月神话

人月神话

这本书,太经典,导致我都不知道怎么写笔记了。 《人月神话》出版距今47年了,算是软件工程领域的经典著作。学计算机的人,几乎没人不知道这本书,很多内容到现在都还在引用和流传,当然它也影响了现代软件工程里面的很多东西。那我就介绍一些概念吧。

软件危机

在计算机刚发明出来的时候,计算机的能力非常有限,只能接收简单的指令和运算,不需要管理也可以开发出简单的软件。

但是,当软件的规模越来越大,复杂度不断增加,软件项目开发维护过程中的问题就逐步暴露出来:软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。所以在上世纪60年代,“软件危机”的概念被提出来。

为了摆脱软件危机,1968 年,北大西洋公约组织的科技委员会召集了一群人开会,第一次提出了“软件工程”(software engineering)这个概念。从此诞生了一门新兴的工程学科:软件工程,它是为研究和克服软件危机而生。

本书主要介绍的是作者开发IBM360的失败体会,也是软件危机的一个案例。

没有银弹

没有银弹的用法就是: xxx没有银弹

在本书中,作者凭借自己在 IBM 管理 2000 人完成大型项目的经验,得出了一个结论:

没有任何技术或管理上的进展, 能够独立许诺十年内使软件系统项目生产率、 可靠性或简洁性获得数量级上的进步。

作者用“没有银弹”来形容这个结论。在欧洲的古老传说中,银色的子弹是能够一击杀死狼人这种怪物的特效武器。我们也可以把银弹理解成是最好的解决办法。

沟通成本和小团队

本书中,作者认为一个团队内部沟通成本和人员数量 n 有关,约等于 n(n-1)/2,也就是说随着团队人员的增加,沟通的成本呈指数级增长。

一个 100 人的团队需要沟通的渠道大概是 100(100-1)/2 = 4950。为了减少沟通成本,我们一般会把团队拆分成若干个小团队,每个小团队 5~7 人负责一部分功能模块的开发和维护。

现在很多管理者把它总结为: 两个披萨原则 。两个披萨能够喂饱一个团队。

复杂性

作者在书中把复杂性分为两种:

一种叫做本质复杂性(Essential Complexity),指的是你要解决的问题本身的复杂性,是无法避免的。

一种叫做附属复杂性(Accidental Complexity),是指我们在解决本质问题时,所采用的解决方案而引入的复杂性。在我们现在的系统中,90% 的工作量都是用来解决附属复杂性的。

国内把一些项目称为屎山,很多时候就是在解决附属复杂性。有人问做一个电商系统,成本是多少?我会回答:几千块,也可能很多亿。

原型设计

IBM360算是上世纪 60 年代最复杂的软件系统之一,也是第一个超大型的软件项目,一共有 1000 名左右的程序员参与了项目的研发,花费了 5000 个人年,最终项目失败。

作者在本书中提到,“在获取和制订软件需求时,将快速原型开发作为迭代计划的一部分”。后来快速原型就逐步发展成为一个开发模型,叫快速原型模型。

这种开发模式主要的特点就是快速开发,快速修改,目的是解决客户需求不明确而且需求多变的问题。

10x程序员

作者,在书中给出了一个统计结果,优秀程序员的开发效率是普通程序员的 10 倍。这就是10x程序员的由来。

后来,成为 10x 程序员是很多程序员的追求,但工作产出并不只是由写代码的效率决定。你觉得还有哪些因素影响你成为10倍程序员呢?

推荐书

《凤凰项目》
《目标》
《人件》
《项目管理修炼之道》
《构建之法》
《持续交付》
评论加载中...