《人月神话》读书心得

序    

     最近在读一本软件工程领域的一部经典著作：《人月神话》。初看书名，肯定想不到这是一本关于软件工程的书籍，或许是一本神话小说，但事实就是如此。这本书细致入微地从多个方面，多个角度切入，深入探讨了软件项目开发的各个过程和可能存在的问题。用通俗易懂的语言和生动形象的例子为我们展现出了真是的软件工程过程。
    有人说：《人月神话》这本书已经畅销20年经久不衰，是计算机和IT领域的“圣经”。通过阅读，个人认为这部著作的确不太容易理解。像这样的书籍，仅仅阅读一次是不够的。或许在我年到半百，从业多年以后再次翻开此书，一定会有完全不一样的感悟吧。人类的智慧真的是无穷无尽的，从上世纪中期的巴贝奇分析机、到1946年第一台电子计算机“埃尼阿克”的诞生，在到现在的大数据、物联网等新技术的逐渐普及。计算机或IT其实是一项非常年轻的技术。短短不到100年的时间，信息技术已经发展到让人惊叹的地步。对于现在的我们，已经不再需要去研究先人已经研究过的东西，也没有必要去走先人已经走过的弯路。我们应该给予前人的经验，继续深入研究。《人月神话》就是多去千万信息技术从业人员积累的宝贵经验。
    什么是软件工程？这个问题在笔者大学本科时就在考虑。网上可以找到各种机构对其的不同定义。比较通用的是：用工程化的方法去研究如何构建可靠的、易用的、高质量的软件产品的学科。过去笔者认为，所谓的软件工程，其实就是编程序，用程序的代码来解决实际生活中的问题。但事实并不是这样，书中告诉我们，软件工程的确是编程序，但准确地讲，是一大群人在一起编程序。如何去协调不同的个体的工作？如何去指导一个团队有条不紊地进行软件开发？如何处理和客户的关系？如何估算和分配具体项目的时间？这就是软件工程要研究的内容。

问题的提出

    焦油坑。书中这样描述软件项目开发的状态。没有好的组织和规划，在一个软件开发的中后期，就会面临这样的问题。当软件的具有相当的规模是，就会出现各种各样的问题，而此时投入越多的工作量，项目就越糟糕。就如同陷入焦油坑的野兽，越挣扎，就陷得越深。就这一点而言，笔者在做课程设计时，就深有体会。由于前期的设计上考虑问题不够周全，导致后期的代码实现时遇到了瓶颈，这个时候，如果你强制修改，那么就会牵一发而动全身。前期的设计至关重要。软件领域有一种说法叫：破窗效应。意思是说，当一座大楼的一扇窗户被打破时，过不了多久，其他的窗户也会被打破。软件开发的过程也是如此，当我们发现软件的一个bug或缺陷，在我们试图修复它时，新的问题就会出现，就如同掉进了无底洞。
    这就是为什么我们学了各种各样的技术，各式各样的编程语言，看似懂得很多，却无法做出一个成熟的产品。其实软件工程重要的不是具体的技术，而是工程化的思想和方法。而这需要进行通过大量的实践来积累。对于一个项目的开发，要关心的问题不仅仅是技术，项目的需求，项目开发的时间估算，经费预算，项目组成员之间沟通和交流的方式，都会影响到一个项目的最终结果。

软件工程是一个团队的工作

    其实书中一直在强调，软件工程是一个团队的工作。事情往往就是这样，当一个人做时，可能并不会有太大的问题，但同样的工作一群人一起去做时，就得考虑很多问题。既要充分发挥每个个体的能力，还有兼顾团队整体成果，这基本上是鱼和熊掌不可兼得的事情。有时候，我们会发现，就一个软件项目小组而言，并不是参与的人员越多，项目的效率就越高。过多的成员意味着更高的沟通成本。
    这里笔者阐述一个简单的例子：包饺子。如果一个人自己去做的话，这项工作确实非常费时。和面、剁馅儿、包饺子、煮饺子，步骤很费时，也很繁琐。如果是多个人一起做，有些步骤就可以并行执行，相对就会节省一些时间。但是这里有一个问题：如果是多个人一起包饺子，要做的饺子的个数也会增加。一个人做只需要做一人份就好，比如30个饺子。如果5个人同时做，就得做5人份，包150个饺子。这样算下来，消耗的时间未必会比人少的时候要少，另外如果参加工作的一些个人工作效率很低的话，或许还会消耗更多的时间。笔者认为，这里一定有一个平衡点，当参与工作的人数的个数是这个平衡点时，消耗的时间是最少的。
    《人月神话》中提出了这样的一个观点，如果一个200人的团队中有20个人是精英，那就开除剩余的180人，他们的工作有项目经理自己完成。也就是说，一个小规模的精英团队的生产效率要比一个大规模的平庸的团队高。人力增加的同时，沟通和交流的成本也在增加，而整个团队的工作能力是二者的差值。书中详细剖析了不同种类的工作的情况。如果一个工作的各个部分是可以分解的，并且各个部分没有关联，那么，参与的人员越多，项目的效率就越高，例如收割小麦；而对于各个部分由严格的时序逻辑的工作，人力的增加，并不会明显提高工作的效率；而对于各个部分具有错综复杂的联系的工作，人力的增加只会起到副作用。工作的效率反而会降低。书中揭示了这样一个道理：人力和时间有时候是不能互换的，即“人”和“月”不一定是互通的。这的确很有道理。
    团队工作的另一个问题就是团队成员之间的沟通和决策的问题。一个软件项目小组如何去沟通？是类似于军队，由领导发号施令，小组成员负责执行？还是类似于议会？团队的决策由小组所有成员共同作出？其实这两种方式各有利弊。军队的管理保证了整个团队的步调一致，令行禁止的方式可以很好地将每个成员的力量积聚在一起，但由于所有的决策都是团队的leader作出的，团队其他成员的能力就不能得到充分的发挥。如果是团队成员共同讨论决策的话，可以很好地利用到每个人的能力，但却会造成一种喋喋不休的局面，即花费很长时间去讨论，却迟迟得不到统一的意见。这种情况下团队成员之间的力量可能会互相抵消。也不会有太好的效果。
    书中提出了一种外科医生团队的模式。由少数人做决策，其他人为其提供支持。工作是多方面的，一个人在工作的某一方面是leader，在另一方面为其他人提供支持。也就是说每个成员都有专攻的领域，同时为其他人提供一定的支持。这种方式看起来结合了以上两种方式的优点，但笔者认为，如果不同的成员之间的工作有冲突的话，这种模式又结合了前两种方式的缺点。是“贵族专制”？还是“民主政治”？或许要依具体情况而定吧？

没有银弹，拥抱变化

     《人月神话》中提出的另外一个概念就是：银弹。银弹的含义最初来源于19世纪欧洲民间传说和哥特小说。这些传说和小说中将银色的子弹描述为驱魔的利器，是针对狼人的特效武器。《人月神话》的作者就将我们要开发的软件比喻为“狼人”，因为软件和“狼人”是类似的，看似正常的软件只要有细微的问题，就会变得“面目全非”。书中提出这样的观点：可以应对所有软件问题的“银弹”是不存在的。作者还在一篇论文中断言：在近10年内，不会有特定的技术和方法，可以使软件项目开发的能力有突破性的进展。如今距离论文发表的10年已经过去，事实证明这样的论断是正确的。
       为什么“没有银弹”，作者认为主要原因在于软件的特性：复杂性、一致性、可变性、和不可见性。笔者认为最根本的原因还是变化。正式可变性造成了软件工程的复杂性，非一致性，和不可见性。其实开发一个软件和建造一座大楼，在思想上是类似的。最大的差别在于，建筑工程的设计实在具体实施前就决定了的，而软件的开发在实现过程中需求的变更时很常见的。软件项目的开发过程必须要适应这种随机的变化。拥抱变化，才是软件工程的精髓所在。 
       没有“银弹”，也就意味着没有一个软件是完美无缺的。这里引用软件测试领域的依据名言：我们只能通过测试证明软件存在bug，却永远无法通过测试证明软件没有bug。IT领域也是优胜劣汰的，一个软件要想生存下来，就必须不停地修改和维护。
       长久以来，人们一直在研究好的软件开发模型去适应这样的变化。从最初的瀑布模型，到后来提出的敏捷软件开发、极限编程，Scrum每一种模式都有它的利弊。过去，笔者一直认为，瀑布模型是落后的模式，敏捷软件开发等其他新提出的方法是先进的做法。但事实可能并不是这样。据了解，为一个火车站或飞机场开发一个运营系统时，从项目开始到最后落成，肯能需要数十年的时间。敏捷开发可能确实在适应需求变更的方面有较好的效果，但是对于这种庞大的系统，前期的设计业是至关重要的。这一点笔者在课程项目的设计上也是深有体会的。
       所以，“没有银弹”并不是意味着我们在软件开发前期不需要周密的设计，进而在出现变更时在作具体的调整。相反，软件的可变化性要求在设计的过程中更加周密，以便可以在需求发生变化时，对软件不会造成太大的影响。一个好的软件工程师眼光要高，要能在短时间内预测到这种变化，从而找到最优的设计。这里阐述一个简单的例子：如果客户需要一个话筒，程序员为他制作了一个有线的话筒，而过一段时间，客户反映话筒的活动范围太小。这时，普通的程序员会把话筒的线加长，而一流的软件工程师会修改为无线话筒。在无线话筒没有出现的年代，显然第一个设计出无线话筒的企业会具有竞争优势。分析和预测需求变更的导向是很难的，这完全取决于软件工程师的经验和阅历。

总结 

       有不少朋友认为IT行业变数太多，所以是“青春饭”，意思就是，当你干到一定的岁数，就一定会被年轻的一辈所取代。 这说明他还没有完全理解软件工程的核心。软件工程的精髓不在具体的技术，而在与其工程学的思想。如何分析市场的需求并预测其未来的导向，如何管理一个软件项目团队，如何去对一个软件项目进行评估和经费预算，不论技术如何发展和更新，这些东西都不会发生太大的变化。近期大数据和云计算技术发展迅猛，好多人都在趋之若鹜地去研究这方面的内容。笔者认为研究具体的技术其实意义不大，大数据技术目前的确很热门，但它总有冷门那一天。当然，软件工程的思想的培养也是建立在对技术的充分了解为的前提的。
       据说每一个成功的软件工程师都读过《人月神话》。本书和其他介绍软件工程的教材不同，重点介绍了软件项目管理的具体细节，而不是去介绍不同的开发模型。很不错的一本书，值得反复拜读。