最烂|世界之最！史上最烂的开发项目：苦撑12年编写600多万行代码( 二 ) 编写|c++|程序员|程序|世界之最

文章插图
有一次，项目里的一个程序员被要求修复一个“右键点击界面会导致整个应用卡死”的bug，经过连续几天的仔细检查，消耗无数耐心之后，他发现，这个右键响应事件其实工作的很正常，只不过这个“正常”过程需要程序花上45分钟，从某种巨大的（静态！）内容库中动态生成每一个菜单项，然后才能把菜单给显示出来。如果这时候你不幸又点了一下右键，不好意思，咱再花45分钟重新生成一下菜单项吧…还有一次，用户报了个“从CD-ROM载入数据失败”的bug。程序员们花了好几个星期来测试分析代码，最后却直接把这个issue标成了“已解决”。因为他们发现，从CD-ROM载入数据的功能其实是好的，问题在于，读取700MB的数据，这程序要花上大概7天时间罢了。还真是特别考验耐心呀。02）版本控制全都是乱来令人难以置信的是，这团队在完全没有版本控制工具的情况下也搞了好几年，直到团队里一个脑子还算清醒的家伙突然想到该用个版本控制工具来管理代码。刚开始的尝试结果并没有让所有人满意，所以这个团队就换到了另外一个版本控制系统。就这么将就了一两年，然后这个版本控制系统不知怎么又抽了个风，把之前所有改动的记录都丢失了。

文章插图
最后这个项目选定的版本控制工具，是一团带有图形用户界面的祸害，一坨从瑞典直接进口的数字化电子垃圾。他们不得不安排了4个人组成一个“版本控制团队”，全职负责维护这个版本控制系统的正常运行。而这直接导致下列情况的出现：首次从版本控制系统中检出文件需要向版本控制团队预约，一般来说在一周后才能获得授权。想修改文件必须经过中层管理人员审批。你需要提前列出需要修改的文件，把列表告诉你的经理，然后打报告给版本控制团队申请，后者大概两天左右会给你反馈。每次对文件的修改都会触发分支，这就意味着你得自己去合并这个文件收到的所有修改。也许你会觉得，项目里这么多文件，两个人改到同一个文件里的几率应该不大，然而实际上，绝大多数改动都集中在同样的大概100来个文件里，所以每次merge都保证让你痛不欲生。在提交修改（检入文件）之前，你还将经受一次精神折磨：你准备提交的代码将被交给一个所谓的自动bug探测程序进行审阅，通过之后还要拿给中层管理人员看过，才能成功提交。不用说，这根本无济于事，bug还是如雨后春笋一样不停冒尖，比大家除bug的速度块多了。更有甚者，对发现的bug数量进行分析后发现，这种“缺陷修正”方式带来的新bug数量是它所修复的bug数量的两倍…版本管理过于简单。旧的版本是1，今天的版本是2，之后的版本是3。没有人能确切地知道具体发给客户的是哪个版本。某些时候，管理层会定下一个所谓的官方交付时间，而这个时间安排跟团队中的任何一种工作计划都毫无关系。当预定的交付日期到来的时候，客户实际上收到的是一张带有安装教程的……空白CD，因为已经有好几个星期没有人能构建可执行程序了。于是，客户发现自己收到的是空白光盘，然后正式投诉，然后收到一个旧版的程序光盘作为应付。而客户之所以会发现程序是旧版的，是因为软件的“关于”页上还写着跟去年那个版本一模一样的日期…

文章插图
03）团队组成更是莫名其妙团队里充斥着这么一大群毫无任何软件工程经验的人，这软件里要是bug不多就还真没天理了吧？还记得上面提到过，管理层曾经决定，要精简一下团队的事吧。按理说，任何一个脑筋正常的经理都会发现，对于这样一个纯软件工程的项目来说，人员开支必定是最主要的开支。然而，这个发现，并不能阻止管理层把所有稍微有点经验的程序员都开了，换上对工资要求低得多的菜鸟。相对的，所有的经理们的饭碗倒是都捧得牢牢的，一点都没受影响。看来《21天自学C++》这样的书一定被他们奉为经典了吧。

文章插图
不，你太天真了，还有《3天学会C++》呢。

文章插图
这团队后来变成什么样了呢？55个人里面，只有20个程序员，剩下35个都是经理。对，你没有看错，这个阵容真是豪华，给每个程序员配备了1.75个经理！没几个经理有软件工程方面的经验。那时候，刚好出了SCO拿着Unix版权起诉Linux用户的事情，就算这整件事不过是虚张声势，但对许多人来说，当时这事还是挺可怕的——要是突然有天你不得不为自由软件付费，那可如何是好啊。技术知识也相当缺乏。都200x年了，这群人还没几个了解互联网的，少数几个熟悉互联网的，也不过就是拿互联网看看小电影而已。要是你提到你在网上看了些啥，得到的都只会是别人的窃笑而已。