史上最烂项目：苦撑12年，600多万行代码( 二 )

而脑子正常的人，则纷纷转向了其他语言和其他项目上去了。要知道，人生苦短啊。
不过，看起来，这家公司并没有跳出这个圈子，还是一个猛子扎进了 C++ 坑里。
退一步说，不管你用的是什么编程语言，维护一个巨大的代码库本身就不是一件容易的事情——而这个项目的代码库居然有 600 多万行之巨。
那， 600 多万行代码是个什么概念？
对比下 Linux 3.13 版内核的代码，在除去内核驱动和架构之外，在 kernel/ 里的源代码也不过就 13 万行左右；另一个例子是著名的编辑器 Emacs ，它因为功能太多太庞大，常被人吐槽成“缺乏一个好编辑器的操作系统” ，但即使如此，它的总源码规模也不过就是 165 万 9 千多行。
就算你特别厉害，一目十行，你大概也要在显示器前面不眠不休花上7天，才能把全部 600 万行代码全部过一遍。
于是我们可以想见，维护这么大一个代码库，可得逼疯多少程序员呢。看看下面这两个例子，我想，如果我是程序员的话，我也会先疯为敬吧。
有一次，项目里的一个程序员被要求修复一个“右键点击界面会导致整个应用卡死”的 bug ，经过连续几天的仔细检查，消耗无数耐心之后，他发现，这个右键响应事件其实工作的很正常，只不过这个“正常”过程需要程序花上 45 分钟，从某种巨大的（静态！）内容库中动态生成每一个菜单项，然后才能把菜单给显示出来。如果这时候你不幸又点了一下右键，不好意思，咱再花 45 分钟重新生成一下菜单项吧…
还有一次，用户报了个“从 CD-ROM 载入数据失败”的 bug。程序员们花了好几个星期来测试分析代码，最后却直接把这个 issue 标成了“已解决” 。因为他们发现，从 CD-ROM 载入数据的功能其实是好的，问题在于，读取 700MB 的数据，这程序要花上大概 7 天时间罢了。
还真是特别考验耐心呀。
版本控制全都是乱来
令人难以置信的是，这团队在完全没有版本控制工具的情况下也搞了好几年，直到团队里一个脑子还算清醒的家伙突然想到该用个版本控制工具来管理代码。刚开始的尝试结果并没有让所有人满意，所以这个团队就换到了另外一个版本控制系统。就这么将就了一两年，然后这个版本控制系统不知怎么又抽了个风，把之前所有改动的记录都丢失了。
最后这个项目选定的版本控制工具，是一团带有图形用户界面的祸害，一坨从瑞典直接进口的数字化电子垃圾。他们不得不安排了4个人组成一个“版本控制团队” ，全职负责维护这个版本控制系统的正常运行。而这直接导致下列情况的出现：

首次从版本控制系统中检出文件需要向版本控制团队预约，一般来说在一周后才能获得授权。
想修改文件必须经过中层管理人员审批。你需要提前列出需要修改的文件，把列表告诉你的经理，然后打报告给版本控制团队申请，后者大概两天左右会给你反馈。
每次对文件的修改都会触发分支，这就意味着你得自己去合并这个文件收到的所有修改。也许你会觉得，项目里这么多文件，两个人改到同一个文件里的几率应该不大，然而实际上，绝大多数改动都集中在同样的大概100来个文件里，所以每次 merge 都保证让你痛不欲生。
在提交修改（检入文件）之前，你还将经受一次精神折磨：你准备提交的代码将被交给一个所谓的自动 bug 探测程序进行审阅，通过之后还要拿给中层管理人员看过，才能成功提交。不用说，这根本无济于事， bug 还是如雨后春笋一样不停冒尖，比大家除 bug 的速度块多了。更有甚者，对发现的 bug 数量进行分析后发现，这种“缺陷修正”方式带来的新 bug 数量是它所修复的 bug 数量的两倍…
- 上一页
- 1
- 2
- 3
- 4
- 下一页