历经了前面的种种困难，才懂得“成功”两字的分量是多么的重，不仅仅是来之不易，更是无法复制的。使得一个项目成功需要很多的因素，俗话说：“好的开始是成功的一半”，读了《人月神话》也就明白了怎样让一个项目有一个好的开始。为了呼应主题，我将好的开始称作“基石”。
效率高和效率低的 实施者之间具体差距非常大，经常达到了数量级的水平，这也就产生了一个最基本的问题：如何分工？这个问题看似简单，实则包含了人员数量，工作种类、管理结构、任务分配等，每一个环节或是步骤都需要严格的考虑，否则就会成为成功路上的一块绊脚石。我不禁反问自己：我们是属于效率高的还是没有效率的？
作者一直重复着这样一个观点：需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果，这一点也暗示系统应该由尽可能少的人员来开发。书中的一个例子十分生动的向我们诠释了这个观点，在一个小组里，最好与最差的生产率平均为10:1，在运行速度和空间上具有5:1的惊人差距，因此在一个200人的项目中，选出25个最能干和最有开发经验的项目经理，开除剩下的。一般来说，大家都会有一种人手越多，工作越容易进行的错觉，将一个很大的任务分成很多小部分，将这些小部分在依照功能再分给各个工作的人员。
我曾经看到这么一个故事，讲的是1个工匠搭建一个小房子需要3个月，于是想到的便是增加人手，那么3个人搭建房子就是1个月，依次类推，9个人需要10天，27个人需要3天，81个人需要1天，直到14348907个人就可以1秒建好一个房子，这个事情是在理想的情况，没有交流、没有流程、没有空间限制等，但现实中是不可能有这种理想的情况，如果软件开发像上面的例子一拥而上的方法，那么开发就是高成本的、速度缓慢的、不充分的、开发出的是无法在概念上进行集成的产品。同样“每个硬币都有两面”，面对真正意义上的大型系统，如果采用小型、精干队伍，则会反过来，变得更慢了，这就出现了一个进退两难的境地：对于效率和概念完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。
首先介绍一下“什么是概念的完整性？”，书中用欧洲不同时期的建筑风格做类比，来讲述设计的一致性和一些的独到之处，这个就像我们面向的编程世界一样，每个系统体现出的概念差异和不一致性甚至是超过了时间悠久的历史建筑。简单一点说，就是一个系统的整体风格是否一致，这个就像一个强迫症的人无法容忍一丝的结合不严，也就是最后的产品是否是浑然一体的。作者主张在系统设计中，概念完整性应该是最重要的考虑因素，这句话可以这么理解，人们在系统设计中难免会有一些十分有创意可以让人们眼前一亮的想法和创意，但是这个会导致一系列连贯的设计思路中断，简而言之就是不提倡特立独行，我看到这里便有个问题悠然而生，就是如果这个创意能够大幅度改善一个程序的设计并且能够使得在技术上有一个大的飞跃，那该怎么办呢？于是出现了贵族专制统治和民主政治便由此而生，如果出现了上述的情况就应该抛弃原来的设计对不同基本概念进行合并，在合并后的系统上重新开始，至于是贵族还是民主应该如何选择？这有涉及到了另一个问题，就是团队的组成方法。
Mills提出了一个解决方案，就是以类似外科手术的方式组建团队，首先就是最为主要的外科医生，为首席程序员，亲自定义功能和性能技术说明书，设计程序，编制源代码等，这个人的定义让我想到了自己小组的组长，他好像就是一个项目的外科医生——首席程序员，他的工作如同以上所述，但之后的分工却和书中有所不同是我们按照了项目的功能模块进行分工，书里是按照职能分工，接下来是副手、管理员、编辑、秘书、程序职员、工具维护人员、测试人员、语言专家，说起来我们其他人的职能更像是一个程序职员，回想我们自己的团队，和这个外科团队有一点相像，组长负责总领全局，不会发生在传统队伍中不必要的讨论与妥协，可以达到客观的一致性。
在书中看到了编辑，于是我想到了我们现在用的GitHub代码托管，通过这几个月的接触与使用自己逐渐的理解了GitHub的便捷，和为什么它是如此的受人们推崇，它好像就是自己的一个小编辑，可以记录自己每一次的修改，可以汇总每一个人对于项目的贡献，不必在共享空间的方面浪费资源了，这个工具的强大是每一个使用过的程序员所共认的。
一个好的团队需要一个好的结构，很庆幸可以遇见一个经验丰富的小组长，能够像进行外科手术中的首席程序员带领我们进行项目的完成，这也就是我所说的“基石”，就是一个团队是否真正的能够有“效率”两个字。
原文地址：https://www.cnblogs.com/Whydd/p/9043537.html