起源：http://tinyurl.com/y55d23p4

• 这我的项目到底啥状况？
• 这我的项目怎么能烂成这样？
• 那，600 多万行代码是个什么概念？
• 不可避免的终局

你见过最烂的我的项目，撑了多长时间才完蛋？六个月？一年？明天介绍的这个奇葩我的项目，岂但一开始就烂得透透的，还硬撑了 12 年多，直到我的项目负责人被逮起来丢进监狱才完事。

到底有多烂？用上面这组惊心动魄的数据通知你↓↓

● 总共 600 多万行 C++ 代码

● 总共 50000 多个类

● 受编译器版本限度，用的 C++ 语法都是古老过期的，只能在某个（早就没有保护）的操作系统上部署

● 基于 CORBA

● 采纳的数据库软件来自一家早就破产的公司

● 好几层相互叠加的层独特组成了用户界面，而且这些层没有一个是由原作者保护的

● 运行一个用户界面须要启动 40-50 个子线程

● 在 32 台并行的机器上须要 48 小时进行编译

● 没有采纳运行库动静链接技术，一个可执行程序就有好几百兆那么大

● 启动这玩意大概须要 15 分钟

● 而后个别 30 秒到 30 分钟内会解体

你从未见过的“天堂级”烂我的项目

十年前的 2008 年，科技博客 projectfailures 爆料，博主那几年曾受雇于法国的一家大型科技企业，参加过一个政府机构委托的软件我的项目，职位是征询参谋。在那里，他亲眼见证了登峰造极的愚昧和疯狂，以及它们在软件开发工作中起到的可怕作用。

十年过来了，这个天堂般的我的项目又被人翻了进去，再次炒的满城风雨，而 projectfailures 博客甚至还就此专门出了一篇回顾。

在文章中，他这样写到：“这曾经不仅仅是什么不足业余能力的问题了，这个我的项目中对人类尊严的有情蹂躏，曾经重大到有的时候让我感觉置身于监狱之中。”

啥啥啥？不过是写点代码而已，除了赔上头发，难道会连命都搭进去吗！？这个我的项目咋这么恐怖啊！

这我的项目到底啥状况？

大概是 1996 年，法国的一个政府机构请某个公司开发一款软件。总的来说这玩意应该不太简单，只不过有一些不太寻常的小问题须要解决罢了。

甲方预付了几百万欧元，打算工期大略 2～3 年左右。于是公司招了几个程序员，开始干活。随着资金陆续到位，这公司开始疯狂招人，每隔三个月左右就把队伍扩充一倍。

后果，7 年过来了，这个我的项目基本还不成型。因为延误造成的罚金每天都达几千欧元。于是管理层决定，要精简一下团队，缩小我的项目开销 —— 具体做法是，把干活的人都开了，另外招一些对软件开发没啥教训的老手来下班。

我的项目开始 10 年后，整个我的项目曾经深陷在劫难的泥潭中，齐全是由纯正的凌乱所组成。于是我的项目的中层管理者终于决定要招一些具备软件工程开发教训的人，来把这个烂摊子从天堂里拖出来。

又过了两年，这我的项目竟然还在苟延残喘。这公司通过给甲方发送金额一直进步的“设计变更”账单，来补救每天产生的工期延误罚金。这都 2008 年了喂！

这我的项目怎么能烂成这样？

01 代码品质惨不忍睹

在语言选择方面，没人敢说 C++ 是种扼要易懂的语言。事实上，在简洁方面，C++ 可能算是最蹩脚的一种编程语言了吧。要晓得，它可是简单到连它的创造者 Bjarne Stroustrup 自己都不敢说本人齐全把握了这门语言。

当然，这不能全怪开发团队。要晓得，在过后，像 C++ 这样领有无尽复杂度的思维迷宫还是大有市场的。许多心愿成为超级程序员的年轻人都对这门听起来超牛逼的语言趋之若鹜。而事实上，这些可怜的娃们，最初大部分都被 C++ 虐惨了，多少美妙的青春，都消耗在重复调试一大段艰涩难懂的代码，消耗在探寻为啥这程序会毫无理由莫名解体这样的事件上了。

而脑子失常的人，则纷纷转向了其余语言和其余我的项目下来了。要晓得，人生苦短啊。

不过，看起来，这家公司并没有跳出这个圈子，还是一个猛子扎进了 C++ 坑里。

退一步说，不论你用的是什么编程语言，保护一个微小的代码库自身就不是一件容易的事件——而这个我的项目的代码库竟然有 600 多万行之巨。

那，600 多万行代码是个什么概念？

比照下 Linux 3.13 版内核的代码，在除去内核驱动和架构之外，在 kernel/ 里的源代码也不过就 13 万行左右；另一个例子是驰名的编辑器 Emacs，它因为性能太多太宏大，常被人吐槽成“不足一个好编辑器的操作系统”，但即使如此，它的总源码规模也不过就是 165 万 9 千多行。

就算你特地厉害，一目十行，你大略也要在显示器后面不眠不休花上 7 天，能力把全副 600 万行代码全副过一遍。

于是咱们能够想见，保护这么大一个代码库，可得逼疯多少程序员呢。看看上面这两个例子，我想，如果我是程序员的话，我也会先疯为敬吧。

有一次，我的项目里的一个程序员被要求修复一个“右键点击界面会导致整个利用卡死”的 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 不多就还真没天理了吧？

还记得下面提到过，管理层已经决定，要精简一下团队的事吧。

按理说，任何一个脑筋失常的经理都会发现，对于这样一个纯软件工程的我的项目来说，人员开销必然是最次要的开销。然而，这个发现，并不能阻止管理层把所有略微有点教训的程序员都开了，换上对工资要求低得多的菜鸟。绝对的，所有的经理们的饭碗倒是都捧得牢牢的，一点都没受影响。

这团队起初变成什么样了呢？55 集体外面，只有 20 个程序员，剩下 35 个都是经理。对，你没有看错，这个阵容真是奢华，给每个程序员装备了 1.75 个经理！

没几个经理有软件工程方面的教训。那时候，刚好出了 SCO 拿着 Unix 版权起诉 Linux 用户的事件，就算这整件事不过是虚张声势，但对许多人来说，过后这事还是挺可怕的 —— 要是忽然有天你不得不为自由软件付费，那可如何是好啊。

技术常识也相当不足。都 200x 年了，这群人还没几个理解互联网的，少数几个相熟互联网的，也不过就是拿互联网看看小电影而已。要是你提到你在网上看了些啥，失去的都只会是他人的窃笑而已。

04 行政管理模式变态的发指

下面的荒诞状况兴许会让人哄堂大笑，但如果你晓得管理层的那群法国佬对员工发动狠来就像是奥斯维辛集中营里的德国鬼子，那你预计就笑不进去了吧。来看看这些官僚到病态的规定吧：

• 禁止早退，所有人必须在上午 9 点前到岗。有一天，人事经理早早就守在公司大门口，把所有 9 点 01 分及之后才到公司的人都当场开革了，程序员、经理和销售，都不能幸免。
• 咖啡机时不时就断供，一断就是好几天。理由当然是跑去喝咖啡的人效率不如坐着干活敲代码的人。不仅如此，每当有领导来开发部视察的时候，这台咖啡机还会被人关掉，省得让领导看到有人“没在干活”。
• 厕所的脏乱差水平能够说是业内绝无仅有的恶心与恐怖。想来这也是管理层防止大家花工夫蹲带薪厕的“高效”政策使然吧。

你可能要问了，这种变态公司，怎么还有人前仆后继的来下班？最次要的是，那段时间法国国内经济正在解体的边缘挣扎（直到现在，法国还没齐全走出这个泥潭），能找到一份足以糊口的工作就已实属不易，工作条件刻薄点也就算了。

不可避免的终局

正如网友评论的那样，着整个我的项目陷入了死循环的链条之中：缺乏经验导致低效，低效导致开销太大，节俭开销又裁掉有教训的人，进一步升高效率。

那么，为什么管理层还坐视这种状况的一直好转呢？归根结底还是对失败的放心。如果你砍掉这个我的项目，就意味着这个我的项目失败了，而负有领导责任的人就是你。如果这我的项目还在苟延残喘，那等你升迁调任之后，这个烂摊子天然由继任者来拾掇啦。

最终，负责这个我的项目的公司领导因为挪用资金等起因被捕，进了监狱，这个在天堂的烈焰中挣扎了十几年的我的项目，才终于宣告终止。

作为整件事件的亲历者，projectfailures 的博主给刚踏入编程世界的年轻人的倡议是：

● 珍视生命，没事别用 C++ 折腾本人；

● 宁愿接一些不那么稳固，但能自在发挥所长的小我的项目，也别贪图安逸去加入什么看起来很冠冕堂皇的工程；

● 面向对象的数据库并不是什么好货色；

● CORBA 应该在烈焰中苦楚的死去；

● 那些愚昧的产品经理，请参照上一条。

最初，如果你感觉你当初的工作很糟心很窝火，心愿这个我的项目能让你开心一点。