人月神话再探

《人月神话》阐述了软件工程的这样一个本质：不能用人数乘以时间来控制软件开发进度
并且作者断言：20年之内不可能产生让软件工程效率有数量级提升的解决方案（银弹）。

如今50多年过去了，依旧没有银弹么？

有人说：

答案是否定的，当初的问题：复杂性，不确定性和变化性已经不复存在了。
50年前，大师开发OS 360的时候，他们做的是一个前人从未做过的事，因此可以这么说；
而50年后的今天，几乎没有任何一个软件是完全全新的，他其中任何功能都一定曾经被开发过了。绝大多数软件开发需要做的就是抄袭和修改。
程序员需要掌握的工具是搜索引擎和粘贴复制，因此人月神话已经不适用了。

有人持相反意见：

从局部来看的确如此，但是总体来看没有什么不同，甚至更严重了
今天的大多数模块和功能的确是已经都实现过了，多数只需要拷贝就行了；反过来，50年前，算法等也是一样。如果将今天的模块映射为昨天的一个算法的话，彼此所处状况是一样的
各种确定的解决方案之间的耦合性，复杂性，不确定性才是软件复杂性的根源。
今天的软件相比50年前的要更大，大数百上千倍，功能复杂数百上千倍，研发人员更多，问题反而是更严重了。

有人说：

面向对象，面向接口和DI概念诞生以来，已经可以有效的将一个问题域划分为几个问题域，几个问题层次的问题。有效的将一个复杂问题切分为几个不那么复杂的问题。
今天我们开发的软件体积和功能都是过去的几百上千倍————按照人月神话产生的复杂度是数千的几何指数增长；
参与人员数量都是以前的几十上百倍————按照人月神话产生的沟通也是几何指数增长，
但是总体研发花费的时间反而更少，经常有每月发布，每周发布，甚至每日发布。
因此可以从统计上宏观断定：当初所期望的让软件开发效率数量级增长的银弹事实上已经有了。

有人反驳：

难道现在可以用堆人头来进行软件开发了么？
很明显不是，人月神话依然有效，问题的本质依然存在。

你提到的现代软件开发之所以体现出“高效率”，是因为他们还停留在搜索修改阶段，还没有真正接触到核心概念的复杂性和变化性；而一但接触到核心概念的复杂性和变化性，效率急剧降低。

君不见几乎所有的软件公司刚开始开发效率都是很高的————在这个阶段还没有接触到复杂性、变化性问题，只是停留在搜索粘贴修改阶段；
过了一段时间，随着业务变化，发展————真正接触到制约软件开发的核心问题，开发效率就急剧降低。
这，是一个普遍现象。

另外，什么时候软件复杂度可以用行数来衡量，而不是用软件的核心抽象————概念，概念的属性和逻辑，概念之间的关系————来衡量。什么时候软件的复杂度可以用人员数量来衡量？

在依然停留在低层次的软件开发阶段就需要如此多人数来维持开发，在复杂度更加高的阶段，怎么可能维持的下去？

马云发飙说刚创业的时候几个人几个月搞定的一个问题现在几百个人一年都搞不定，阿里都开始搞中台了————然而两年过去了，也是轰轰烈烈到悄无声息

但是，作者以为，我已经找到了银弹，至少是一颗镀银子弹

//TODO 请看下一章节《人月问题的原因》