[Geekland]The Mythical Man-Month

人月神话是一本软件工程领域的经典，缘起是一个不能上网的夜晚和Brooks所获得的Turning Awards。

在我们这个星球上，如果说还有哪些软件开发依然遵循类似书中描述的OS/360开发模式的话，那么毫无疑问，电信行业的软件开发应该可以算作仅有几个之一。我自己也是在看了这本书以后，才明白我目前的公司组织架构，流程，角色，不同角色的义务和权利等等原来是有来由的。拥有一副清晰的图景我以为是必要的。

原本我想按照原文的顺序每章写一个简单的介绍和评价，不过作者再次证明了计算机行业是一个应用心理学的行业，他非常体贴在最后用单独一章（Propositions of the Mythical Man-Month: True or False？）给出了每章的简短提要和一些核心观点。原作者自己的理解肯定比我要正确，所以下面就讲一讲印象特别深的几个地方。

在MMM这本书的一开头，Brooks就用一幅画表明了一个隐喻（metaphor：在CS，特别是软件开发这个领域，一定要理解一些metaphor，不过幸好这个对我们中国人不是很困难，中国人一向享有形象思维的美誉，这是从风雅颂以来确立的名物传统）：焦油坑中的巨兽。作者Brooks用这metaphor来表征软件开发过程的困难，那么困难在那里呢？困难能不能克服呢？

我以为Brooks论证了软件开发过程中的两个方面的困难：大型软件系统开发所需要的人手和人与人之间交流沟通的困难所产生的矛盾，软件开发上的本质困难。我先讲后面那个，再讲前面的。和书中的顺序有点不一样，因为第二个问题...

软件开发过程中出现的困难能不能解决，我以为Brooks的答案是有些可以克服，比如沟通问题，有些就不大好办，比如本质困难。具体可以参见文中那篇著名的论文“没有银弹”，大概得意思是说软件是现实世界的模拟，而现实世界是纷扰复杂的，所以说软件过程从本质上来说就是困难的。举一个我们熟悉的例子，比如打电话，我们理解起来简单，各有一个号码，拨通就OK了，但是我们现在知道，所有在物理层，不管是空口还是核心网，传输的只是一些数据或者说信号，而打一个电话中发生了多少逻辑业务上的处理呢？所有这些都是软件来模拟的。所以软件从本质上是复杂的，困难的。一些诸如工具等等带来的进步不可能从根本上改变目前的现状，Brooks甚至提到了I型AI，II型AI，（Turning Awards不是白拿的）这些有兴趣的老大们可以自己去看看。

下面回到第一个问题，也许能能过努力改善的地方，这也是Brooks这本书的目的。Brooks在自己的和同时代很多其他人经验基础上，总结软件工程上非常多的实用方法和指导意见，个人以为我们目前所处的系统大模大样就是书中的蓝图规划出来的。

Brooks提出了所谓的Brooks法则：

向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）

为什么这么说呢？按照Brooks的说法，在一个n个人的团队中，每两个人一个接口的话，一共有C n 2=n·(n-1)/2个接口，每m（1<=m<=n）个人是一个内部团队的话，一共有n!个内部团队。这就是巴别塔为什么会倒掉的原因，所以要加强沟通的强度和效率，而最有效的沟通方式无疑是face-to-face,加上一张白纸一支笔。不论是email或者phone都不能取代f2f的交流。

组内的架构书中推荐了外科手术式的团队，从我个人来说，我觉得团队内部一个Architecture+ assoiated Architecture，能够cover所有相关的技术问题。一个Documents管理员角色和一个tools/environment管理者角色是非常必要的，这些完全可以是兼职的，能够节省所有人的时间，提高效率。而documents目前来看，无疑wiki是非常好一种形式。

最后一个是角色的权利和义务，虽然我们都是来自第一线的开发人员，但是软件从根本上是一种创造性活动，在一种架构之内并不意味要完全要压制我们自己的创造力，也就是说，我们不光要强调我们的义务，同时还应该实现自己的权利。按照Geek社区的说法就是Do it youself/Just do it。我们完全可以根据实际情况来改进流程，创造性地完成工作。实际上，现在的一些软件工程方法，比如敏捷方法，就把个人的能动性突出出来，Brooks显然也意识到了这个问题的重要性，只不过大大型软件系统中，需要突出的重点不同而已，最重要的问题显然是沟通。

最后，我想要说明一下的是，虽然书中描述的蓝图使一些已经验证了的方法，而且目前看来我们的系统正是按照这个蓝图组织起来，不过这并不表明只有这一种方法做事，另一本软件工程领域的名著“大教堂和市集”，作者Raymond就令人信服的论证了在开源社区中采用的另一种方法，几乎是和MMM针锋相对的做法（从名字就可以看出:）所取得的巨大成功，虽然我个人觉得OS社区的成功至今看起来有一些迷雾，也许一个合理的解释是大多数现实当中运行的系统虽然大模大样是按照Brooks的蓝图设计的，可惜的是在具体施行上有很大的偏差，以致于一些愤怒的programmer不得不在OS社区中发泄自己的创造力（纯属瞎掰，仅供一笑:)