团队开发的悲剧

团队开发的悲剧多种多样，不过总归和人有关系，更准确的说，应该是和“人之间”有关系。最近正好看了《人月神话》这本老得不得了的书（各位见笑，不是我不爱看书，是因为此书过于抢手，一直没借到），里面说了“主要问题”和“次要问题”，个人觉得这个翻译并不好，实际上应该是“本质问题”和“附带问题”。所谓“本质问题”，我觉得就是我这里所说的”人之间“的问题。

 

当然了，人家Brooks所站在的角度比较高，因此它的焦油坑也显得比较有档次。 而我呢，虽说也算是在国内某个领域内独占鳌头，要不是亲眼所见，还真是无法相信会存在这种低级别的悲剧。（“啊！你那个破公司那个鳌头有多大？”这个限于权限，我不可能知道整个的情况，我们这个部门还是知道的，不过基于保密，我也不能说。这么说吧，我们部门开发的产品年营收级别在10⁷这个以上，而我们这个产品还只是一个很小的小头。）

 

嗯，那我遇到了什么样的“焦油坑”呢？首先第一个最大的问题是，开发规范问题。这个问题范围很广，包括命名、风格、文档等等。“嗯，这么简单一个问题，都做不好？ ”抱歉，这就是现状。我不清楚大多数公司是什么样一个情况，但以此可以合理猜测，和我所见到的水平一致，甚至更差的公司应该是不少的。这里面存在一个实际情况：有很多人打心眼里面不重视这个问题。我觉得这可能和个人英雄主义有关系，因为我自己也曾经觉得比如注释这样的东西，并非最重要的。然而，当我工作一段时间之后才发现，这是因为我没有考虑另一个问题所导致的错误结论。所谓的另一个问题是：你的同事的心智水平是你的百分之多少？

 

这么写似乎有点伤人自尊，但确实是实情。Linus说过“Read the f*** code”，但是问题是，很多人就是读不懂代码。就好比写一本英文的产品说明书，可能你英文专业8级，写的很流畅。可是后面跟着维护的人就是读不懂，当他们面对一个“把100瓦修改成200瓦”的任务时，可能就出现见胡子就是爹的情况，乱改一气。于是，尽管你的英文说明书清楚写明100 Watt，你还是得要乖乖的注释上“100瓦”。我个人的体会是，其实软件工程的问题与你的团队的水平是有很大关系的。如果你那里都是Linus和Anders，那么可能只需要10000行代码加1行注释。如果你团队水平不行，那就需要要求注释越多越好。或者说，团队开发最需要注意的，正是那些掉队的人。

 

此外，团队开发最大的成本在于沟通，尤其是产生误解的时候。 所以，开发规范绝对是技术头头第一件必须要考虑，并且贯彻执行的问题。我记得之前有人这么说：“我以前的老板要求每个人写出来的代码一摸一样，这真是一个很荒谬的想法。”我听了感到无比的吃惊，这样的说法才真是荒谬得无以复加。人月神话中，把开发比作外壳手术，并以此为参考指出人员的配置方式——专家团队。我这里也做另一个比喻：开发团队和行军打仗没有什么差异，拼的是整个团队，尤其是纪律性、统一性。统一的开发规范，也许会让很多人觉得不爽，因为不符合他自己的审美观。但是，当我们考虑到这是一个团队的时候，你就必须清楚地意识到，不统一的规范，会造成很多沟通的成本。而且，对于每一个人，如果连规范统一都不予以重视，又如何重视文档呢，如何重视质量呢？

 

如果你是Leader，如果你有足够的权利，第一件要做的事情是什么？不要做什么技术选型，不要搞什么需求分析，不要思考是scrum还是xp。首先一定要制定并贯彻执行一个统一的规范。否则，你一定会遇到一个“第一系统效应”（人月神话没提，估计是Brooks的团队水平足够高吧）：在混乱和灾难的高空走钢丝，好不容易走过去了，你第一个念头就是推倒重来，因为那根本就是一个无法维护的东西。如果你没有清楚认识到第一系统效应，那么第二系统效应能否遇到还真不一定呢。