今天我也来了一下《人月神话》，相信这本书应该是非常知名的，很多人都看过，就算没有看过的话，应该对这本书的名还是有很大的了解的。

我第一次听到书名的时候，感觉这本书会是神神叨叨的，阅读难度非常大，但实际上这本书要传达的概念非常简单。用一句话来总结来说，那就是软件工程并不能够通过增加程序员的方式来无限制分拆软件工程项目，来实现工期线性缩短，这里面人/月指的就是一人一个月能开发的工作量。在我们公司一般用人/日的折算方式比较多，毕竟咱们中国及其在乎效率，衡量成本恨不得用人/分钟。

本意上就指的是在我们针对这个软件工程的项目里，可以通过加人的方式来提升效率，降低整体工期。但《人月神话》这本书就提醒我们，并不是所有的软件项目都能够通过加人的方式能够缩短时间的，也就是工期缩短和人数并不是反比例关系。

原因也很简单，在我们人数越多的情况下的话，就会有网状的沟通成本。而在人多到一定的节点的情况下的话，成本就会指数级的上升。因而实际上把增加人的这个提升的效率实际上又通过沟通复杂度的方式又把整体效率降低下来，所以最终无法实现工期的缩短。

在这里说一下我这边的实际经验。在刚开始接入软件工程项目的时候，我往往也认为人日是可以通过加人的方式来缩短工期的。而且在实践中我也确实处理了非常多的项目，都是通过加人的方式能够大幅的缩短工期，甚至能够几倍的降低工期，比如有时候一个项目一个人投入需要15天，再增加一个人就可以直接降低到7天。所以有些时候就给了我一个误解，我认为大部分的项目都能够通过加人的方式达到一个缩短工期目的。

而在我最近经历了一个特别大的项目，特别复杂度的项目的情况下的话，我就发现通过加人的方式，效率并未得能够提高。因为模块过于复杂，导致我不断的要跟另外的同学来沟通这个模块对于上下文的依赖，并且在测试的时候也非常的麻烦，因为你很难明白全局的背景，所以会大幅度的加高了协同成本。这个项目我们只有三个人在写，就已经出现了沟通方面的一些难度，想象一下，如果加到十个人，这个成本跟你三个人做可能是一样的，甚至还可能会更慢。

人月神话的限制条件，就是大型耦合型模块。如果只是简单性质的、容易划分边界的，比如只是页面上的差异，那完全可以通过堆人的方式实现工期快速缩短。当我们这边共同来协作完成一个大型的耦合性软件工程，就完全不一样了，这时候人月神话的约束就出来了。诸如要写一个Windows操作系统这样的一个软件就属于重度耦合和相互依赖、非常复杂的一个软件产品。但是像很多页面型的功能产品几乎相互几乎没有任何的依赖关系，这种就往往能够直接分拆出各个模块，由小团队来协作，能够通过加人的方式能够快速的降低工期。

我这边有个前端同学喜欢用一句话来总结这种《人月神话》碰到的困境，那就是一个女人生一个孩子需要十个月。但是给了十个女人，你还是需要一个十个月，并不是给十个女人，生孩子这件事就能够降低到一个月的，这就是事物本质上的复杂度引起的。特别对于复杂耦合型的模块，无法通过加人能够缩短工期的一种形象的描述。

所以这里面给我们一个经验，首先我们要衡量一个软件的模块复杂度，到底是不是松耦合的还是紧耦合的？如果是紧耦合的话，那么就会碰到《人月神话》这样的困境，你不可能通过加人能够无限制的缩短工期。

而相反，如果软件可以无限分拆出松耦合的模块，诸如以页面的方式来做隔离，那么就能够在一定程度上面通过加人的方式来大幅的缩减成本。

这个思想也就是微服务的思想之一，微服务就是通过模块之间的进一步划分，划分成最小的服务化的接口，使得服务之间相互独立，这样就可以通过加人的方式，通过小团队的协作来构建出大型项目。

我们可以看到通过微服务这样划分，可以把模块从头到后都进行闭环，包括数据库代码，缓存，中间件等等都是相互隔离的，只是通过API的方式来相互通信和协作，这样的话就大大减少了沟通和协同的成本从而避免了人月神话的约束。

所以理解了《人月神话》，并且更加理解了软件工程的本质，则使得我们在软件工程的组织和架构设计里面会更加显得游刃有余。

公众号：ali老蒋