loonggg
读完需要
4
分钟速读仅需 2 分钟
这是我在知乎上看到的一个问题，我相信作为我们程序员来讲，内心肯定都知道答案了。肯定不可能的，除非阿里的程序员把代码拿出来，然后再部署一套，毕竟全世界的程序员也包括阿里的程序员嘛。但是，这个肯定不是题主想问的。
其实，我更想通过这个问题给大家推荐一本书，那就是《人月神话》，相信很多程序员都听过这本书，我不知道又有多少程序员读过这本书呢？我只是想说：对于程序员来讲，如果你想开阔自己的眼界，丰富自己的知识，软件工程和软件管理类的书籍是必读的书目，而且你如果又想往技术管理的方向进阶的话。
这个问题，如果从《人月神话》的角度去回答的话，应该是这样的：
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但 并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程 序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会 导致灾难的循环。
在《人月神话》中有这么一句话：
简单、武断地重复一下 Brooks 法则：向进度落后的项目中增加人手，只会使进度更加落后。
在《人月神话》中，它讲到了人们的一个谬误：
那就是很多人的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
什么意思呢？
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。但是在我们的软件编程，系统编程中，这是不可能的。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。无论多少个母亲，孕育一个生命都需要十个月。不会说因为一个母亲怀孕 10 个月能够生出一个孩子，所以我找 10 个母亲，就可以在一个月内生出一个孩子来。
对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些。因为可分解，但是每个子任务之间又沟通密切的话，随着人数的越多参与，沟通的时间成本也会显现，所以，人数越多可能沟通的时间成本也会导致项目延期，开发的很慢。
沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化 。
软件开发本质上是一项系统工作 —— 错综复杂关系下的一种实践 —— 沟通、交流 的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手， 实际上是延长了，而不是缩短了时间进度。
所以，你说呢？如果集中全世界程序员的力量，三天之内能实现一个手机淘宝吗？答案是显而易见的，不可能。因为人越多，就越乱。可能光架构的设计这些程序员就能争吵一个月。尤其是集中全世界的精英程序员来开发的话，协调沟通，够大家喝一壶的，大家吵吵一个月都未必能够进入开发阶段。
最后，我再给大家强烈推荐一下：《人月神话》这本书籍非常值得一读。另外，我给大家整理一份《程序员必读的软件工程书单》，里面给大家推荐一些非常值得读的，在业界非常经典的软件工程学的书籍。点击“阅读原文”，可以直接查看推荐的书单，或者在公众号对话框内，回复关键字：“工程书单”，即可获取。
在最后的最后，我统计一下大家，有多少人读过《人月神话》这本书，请大家积极参与投票。
--- 特别推荐 ---
特别推荐：一个新的优质的推荐高效工具，软件，插件的公众号，每天给大家分享优秀的效率工具，「程序员掘金」，专门为程序员挖掘好东西的一个公众号，非常值得大家关注。
