乱战

　　我这边没事了，CM小组却开始焦头烂额。

　　CM模块几次编译均告失败，而法国同事提供的编译错误日志乱七八糟，毫无帮助。原来，我们项目当时尚未采用分布式编译技术，为了缩短编译时间（仅仅某一个子模块单机重新编译就需要18小时），法国的集成测试团队自行编写了一个脚本，开启几路进程并行编译各个子目录。这个脚本写得过于简单，几路进程的输出信息全都杂七杂八搅到了一块儿，以至于CM小组研究了几天，连到底哪个子目录编译不过都没闹明白！

　　CM小组尝试向风雨飘摇中的法国集成测试团队请求帮助：“你们能否用单路进程编译CM模块的各个子目录，将错误信息提供给

　　我们？”

　　法国人回答：“请中国团队尽快修复编译，你们堵住了整个项目！”

　　CM小组解释说：“我们正在努力，你们能不能帮忙……”

　　法国人回答：“请中国团队尽快修复编译，你们堵住了整个项目！”

　　CM小组再次尝试：“这一错误本地不能复现，而编译日志……”

　　法国人回答，并且抄送各路神仙：“请中国团队尽快修复编译，你们堵住了整个项目！”

　　外事不靖，内部也不安宁：CM小组的小组长B和技术骨干S此刻正在斗气！从一开始，B就将编译错误的排查工作分配给自己和另一位同事，没有邀请S介入，而S也不主动过问。没想到这么一个乍看上去再简单不过的错误一拖就是好几天，这样一来，双方陷入僵局。站在B的角度，如果连个编译问题自己都解决不了，还得请S来当救兵，这不是坐实了自己不懂技术的指控吗，这张脸以后还怎么搁？再说S一直面无表情地坐在自己的电脑前做自己那一摊事情，一句问话没有，这不摆明了是要袖手旁观吗？而S也有自己的苦衷：自己要是一开始就主动介入倒也罢了，如果拖到现在才出手，那怎么解释自己前几天不闻不问的态度？就算自己辩解说确实没有端架子、看领导笑话的意思，完完全全是在服从领导安排，也得有人信啊！双方有一点想法倒是共同的：这个编译错误赶紧消失了吧……

　　既然CM小组迟迟不能修复编译，顺理成章地，项目经理（一个不偏不倚的法籍华人）开始找他们的上级，也就是我们共同的经理T。然而—她找不到T！事情就是这么凑巧，虽然T平时就神龙见首不见尾，可像这次这样整个礼拜办公室都不怎么见人影、写信也不太回的情况还真不多。连续几天，项目经理从法国给T的座机打电话，按说这是法国的休息时间，中国的上班时间，可是法国那边有人打，中国这边没人接。电话留言、电子邮件都不好使。项目经理急了，电子邮件写得越来越不客气，每封信的结尾都是同一句话—“T在哪里！”……

　　事情终于惊动了上面，领导出来问话了：“发生了什么事？为什么会耽误到现在？”法国团队再次暗示中国团队无能，中国团队则强调本地无法复现，必须法国团队配合，项目经理在居中调解的同时狠狠地告了T一状……领导不愧是领导，跳过T的事情不提，和蔼可亲地建议法国团队考虑中国团队的合理要求……事情终于走上正轨。法国团队终于按照CM小组的建议尝试单路编译；与此同时，B主动去征求S的意见，问他是否愿意参与排查，而S也立刻答应下来；T又神秘地出现在办公室里，如果这有关系的话……经过整整一周的纷扰，周五，编译终于成功。

　　那么，这一编译错误到底是如何产生的呢？说起来，这居然还与前述混乱的版本计划有关。在4.0版本中，出于兼容旧有设备的需要，CM模块中有些文件按照foo_V4.h的格式命名，后来升级到4.1、4.2版本后文件内容相应修改，文件名保持不变。可是5.0版本实际上是4.1、4.2版本的综合，CM小组被迫把4.1、4.2这两个版本的foo_V4.h文件都引入5.0版本，文件名分别命名为foo_V41.h和foo_V42.h以示区别。换言之，文件名变长了一个字符，而这就导致法国集成测试团队的编译脚本中的命令行超过了最大长度的限制……

　　尾声

　　软件工程应该怎样做？我本来以为CMM、TL 9000等是王道，经历这一风波我才深切地体会到，再好的流程与制度也经不住扯淡啊。人和最重要。

　　无论版本号如何，我们的产品终究还是销路不畅。新任CEO上台后，大刀阔斧厉行改革，将整条产品线出售。毕竟，对于IT业来说，创新才是利润之源，单纯的削减成本没有出路。基于这一认识，我转投互联网公司，从此踏上新的征程……