600万行代码！计划两年结果做了十二年，直到负责人被丢进监狱

作者丨佚名

译者丨核子可乐

策划丨Tina

我待的不是一家企业，而是监狱？

一个原本复杂性不高、预计只需两年的政府项目，实际上最后却用了十二年，直到项目负责人被逮起来丢进监狱才完事。一位亲身经历这个项目的程序员，在之后十年间断断续续写了好几篇博客，用以“自我疗伤”。虽然这些经历已成过去式，但是放在 2020 年的今天来看，也不过时。

我亲眼看到的一切，完全超越我在多年软件工程实践中积累下的基本认知。在这里，管理者的问题不只是缺乏专业能力，更多是对人格尊严的轻视，这让我感觉自己待的不是一家企业，而是监狱。

先说说这个项目的基本情况：

• 600 万行代码
• 基于 C++ 语言
• 5 万多个类
• 项目使用的 C++ 编写风格早已过时，原有代码被牢牢锁定在特定编译器版本上，且仅通过单一（超过维护期）操作系统进行分发
• 基于 CORBA
• 数据库软件由一家已经破产的公司提供
• 图形用户界面中包含无数个层，其中不少已经停止维护
• 32 台并行设备，需要 48 小时才能 build 完成
• 运行一套用户界面需要 40 到 50 个进程同时运行
• 没有动态库链接：可执行文件的体积高达数百 MB
• 启动时间约为 15 分钟
• 两次崩溃间的平均间隔时长：30 秒到 30 分钟

也就是说，这个项目需要维护多达 600 万行的代码，就算是一秒能阅读一行，大家也得在屏幕前坐整整 70 天才看得完。这么多的代码，每次编译，还得 32 台机器、运行 48 个小时才能完成。

曾经有一次，项目组的一位开发人员负责检查右键单击界面为什么会导致应用程序卡死这么一个 Bug。经过几天的耐心检查后，他发现其实这并不是一个 Bug，只是菜单弹出速度比较慢，弹出一次大约需要 45 分钟。

为这个项目提供数据库的企业也没能撑到这个法国政府项目成功的那一天——数据库公司先倒闭了。但是，这个项目又写死在了这个数据库上，所以也只能就这么继续用下去。

此外，公司还不断的解雇人。迟到一分钟？会被解雇！穿短裤上班？会被解雇！最后留下的项目经理比团队成员还多，55 名项目成员之中有 20 名开发者和 35 名经理。也就是说两个项目经理才能分到一位程序员来给他干活儿。

这样一个项目，是怎么被“炼”出来的？

1 选择了超难学习的 C++ 语言来实现项目

直到现在很多人还是觉得 C++ 是种好语言，是软件开发的理想工具选项。

但是单从复杂性角度来看，C++ 可能是世界上最差劲的计算机语言之一。

这种语言最初由一个人，或者最多是一小撮人设计而成。多年以来，随着 C++ 语言的应用范围不断增长，最终出现了“按委员会导向进行设计”的可怕制度。CORBA 就是这么来的。

如果大家用过 C++，一定了解这个语言需要长时间的学习和不断的练习才能被掌握。你甚至需要做无数个微小且毫无意义的练手项目。而且很有可能永远弄不明白它是怎么编译出来的。以至于它的创造者 Stroustrup 都承认自己没有完全搞清楚这种语言。

在《高效 C++（Effective C++）》中，Scott Meyers 警告称 C++ 中包含多种子语言。他列举了 C 语言、Object-Oriented C、Templates 以及 STL，但如果仔细观察，大家会发现 C++ 中包含的风格基本上跟编译器选项的数量一样多。

把这个数字乘以平台数量，乘以编程规则与建议数量，再乘以活跃程序员的数量，就能得出整个社群的总体规模。最重要的是 ISO 委员会还会不时发布新版本来进一步强化这种复杂性。我接触过的 C++ 大师们基本有个共性，就是他们承认自己只能弄明白 C++ 语言中大概 90% 的部分，这个比例已经足够让他们名留青史了。

使用没经验的 C++ 程序员

这个项目开始的时候，政府方面先期支付了几百万欧元，开发计划在两到三年之内完成。公司聘请了几位 C++ 软件专家来推动这个工作。随着资金的逐步落实，每 3 个月左右就会提升一次团队规模。

由于采用的是 C++ 语言，而每个人对 C++ 的理解程度又都不一样，某些问题有时候只能由其中一位专家负责解决。也就是说，如果只有一名程序员有能力维护项目中的某个高难度部分，但他离职了，就没人能读完或者理解他的代码，那么这部分就没法维护了。

这个项目进行七年之后仍然没能达到足以交付的水平，公司需要每天支付数千欧元的罚款。管理层最终决定降低成本并解雇所有具备开发经验的员工，转而招聘了一批没有任何软件工程经历的新手。

那阵子，很多团队成员的桌上都放着一本《C++ 傻瓜入门》。

悲催的是，对于项目中的新手来说，他们没有能力消化 C++ 语言的极高复杂性。而且这些人用在学习语言及编译器方面的时间，要远远多于开发实际成果的时间。

十年之后，考虑到项目的灾难性现状，公司的中层管理者决定再聘请一批有经验的软件工程人员帮助项目重回正轨。

版本不兼容

除复杂性外，C++ 还存在二进制兼容性（ABI）方面的问题。在对象文件内对 C++ 对象进行命名的具体方式实现标准化之前，我们根本无法将两个不同编译器产生的两个对象进行相互链接。对于库供应商来说，这意味着我们必须直接发布源代码。而一旦以源代码的形式集成第三方库，就意味着我们必须引入所有必要的编译环境——这些环境可能与当前环境兼容，也可能不兼容。这样，工作的重点就从开发实际功能，变成了集成一套外部库，然后弄清楚该如何对该库进行编译。

虽然新版本已经解决了问题，但时至今日生产环境中仍存在大量旧系统。而且由于二进制兼容性问题，这些陈旧系统一直无法与 C++ 编译器良好对接。要想彻底消除这个问题，可能得等到几十年之后了。

有些人可能会说：“如果 C++ 真那么垃圾，为什么还有那么多人在用？”要知道，这个项目开始于十年前，除了 C++ 没别的可供选择呀。现在的大多数软件工程师都不会这样故意给自己找麻烦。

根据现在 Slashdhot 上发布的 C++ 相关内容来看，躲着 C++ 走已经基本成为一种共识。

2 疯狂的版本控制

这个项目进行了好几年，团队里终于有人想到应该使用版本控制工具。最初选择的版本控制工具没能起效，所以大家还不断的变更管理工具。每一次变更，都导致原有记录彻底丢失。最终选择的是一款真正灾难级的来自瑞典的图形用户界面。

项目组还专门建立了一支有四名成员的团队，致力于解决版本控制软件的基本维护工作，其中包括：

• 首先提交申请，与版本控制团队约定沟通时间，整个批准周期大概是一个礼拜。
• 没有中层管理的授权，不得编辑文件。员工必须事先上报自己想要编辑的文件，而后发送正式的审批申请，申请会被递交至版本控制小组，他们可能会在接下来的几天内实际执行。
• 对代码的每一次修改都会创造出新的分支，所以必须得想办法合并并回收所有修改内容。由于存储有大量文件，所以各位可能觉得不会同时有两个人在修改同一个文件，对吧？但事实证明，大部分修改都集中在大约 100 个文件身上。
• 更新过程同样非常痛苦：提交的代码将首先接受自动 bug 检测软件的审查，而后再由中层管理进行人工审查。可以想见，缓慢的审查速度导致 bug 的产生速度比清理速度快得多。认真查看已经报备的 bug，大家会发现每一次 bug 修复都会带来两倍的新增 bug。
• 版本分配方式简单而粗暴：旧软件是第 1 版，目前的软件是第 2 版，未来的软件是第 3 版。实际上，根本没人知道最终交付给客户的会是第几版。

终于有一天，项目正式交付了——而且这个时间已经不是当初商定好的时间了。在项目截止的那天，他们交给客户的实际是一张包含安装说明的空白 CD，因为到这时全部开发结果已经不可能在几周之内完成 build。客户发现了其中的猫腻，并正式发起诉讼，公司就赶紧把去年的旧版本再交上去，而且丝毫不打算掩饰下。

3 随意解雇员工

大型企业所代表的不只是沉重的人员结构负担和金字塔上面的复杂体系，其中更存在着无数所谓中层管理人员——他们专门负责收拾基层员工，这就是他们的全部工作内容。从中层管理者向新人介绍工作内容的那一刻开始，影响就已经出现了——他们只知道下命令，不理会任何底层反馈。

有很多极端的例子：

• 早上九点到单位，一分钟也不能迟到。有一天，有位经理站在大门口，每位迟到的员工、哪怕只迟到了一分钟，都会被当场开除——其中包括几名经理以及销售人员。
• 咖啡机每隔几天就会出毛病。这显然是人为搞出来的，可能管理者们认为总喝咖啡也影响工作效率。毕竟省下这段时间，程序员完全可以多码几行代码。
• 厕所从来打扫不干净，看着让人恶心。这可能是为了提高生产效率：减少待在洗手间里的时间，就能让员工拿出更多时间干活。

很多人不相信上班迟到一分钟就会被当场开除，但这就是事实。因为请了外包公司，所以企业可以随时撕毁合同，这也是外包公司的意义所在。曾经有一家外包公司的员工被解雇，法院方面用了两年时间进行调查判决，最终只获得 3 万块的赔偿。相信很多朋友都觉得这么点钱不值得耗费巨量的时间心力，而且大多数人甚至不会提起诉讼。

哪怕是直接跟甲方签了合同，情况也好不到哪去。公司可以因重大过错为由把你当场开除，然后等待几年的漫长调查再跟你出庭对质。但面临失业压力的可是我们自己，谁愿意拿出两年时间跟前任雇主没完没了地扯皮？

这家企业，还曾经以穿短裤上班为由解雇员工。这位员工选择诉讼并成功胜诉，但公司一方最终还是把禁止穿短裤上班写进了制度。

不断的解雇导致新人的平均留存时长仅为 3 个月，这还是因为法国法律规定员工至少要待满 3 个月才能被公司解雇。

最后剩下的项目经理比团队成员还多，55 名团队成员之中有 20 名开发者，和 35 名经理。也就是说两个项目经理才能分到一位程序员来给他干活儿。

经理们不断组织各种会议，不断发布内容完全相同的 PPT 演示资料，而开发者们则在宽敞的开放式办公区内聊天打发时间。这帮经理也都没什么软件工程方面的经验，技术水平低下。经理们对互联网没什么了解，最多只听说过色情网站。听到他们讨论互联网，员工也只能保持尴尬而不失礼貌的微笑。

4 官僚的管理方法

因为不断的随意解雇员工，也没人敢说个“不”字，最终惯坏了这批高层领导，导致整个企业的管理作风极其官僚：

在现场露个脸，比处理实际工作更重要

工作到底做成个什么样子，往往没人关心——但是，你绝对不能迟到、不能早退、不能不参加会议。正常下班时间之后，你甚至没什么正事可做，但你得在那待着，跟同事聊聊天、喝喝茶、上上网。这些都行，但不许回家，否则你就赶不上下一波升职加薪。这里的基本思路是，你应该把自己的生命奉献给公司。放弃家庭生活，最好能不拿薪水——无论你前一天加班加点赶出多少工作，第二天都一定不能迟到。

上报的内容不重要，但文本格式必须拿捏得死死的

作为一名员工，你辛辛苦苦完成了一份报告，自认为这份报告内容翔实、建议中肯。但是，领导首先看的不是内容，是文本格式是否正确。如果公司徽标颜色不对或者 Word 文档的格式没按要求调整，那一切肯定被打回重来。

电脑一水的微软标配

在这里，每个人都用 Windows，通过 IE 浏览网页，用 Exchange 发送邮件，使用 Word 编辑文档。如果文档里的条目数量不超过 10 条，请把它做成 PPT。10 到 20 条之间，那就是 Word 格式。如果条目更多，只能用 Excel 电子表格。IETF 和 RFC？那不是开源的东西吗？我们可不用那种“没版权”的东西。

Java 是唯一的语言，XML 拯救一切

其他编程语言都是给麻省理工那帮科学家准备的。我们只用行业中最主流的语言选项。如果其他人都在用，那肯定不会有错。

花钱就是为了让程序员写代码的

软件工程就是把简单的事情复杂化——本质上不就是由廉价劳动力在那写点代码吗？要开发软件，需要的就只有页面和代码页，这些页面必须是纯 ASCII 文件。程序员（或者叫码农）按代码行数计算报酬，代码行的生产跟编码器数据 / 编码耗费的时长保持线性比例关系。总而言之，花钱就是为了让程序员写代码的，其他事情你们不要掺和。

你知道就行，别往下传

你得把自己掌握的一切有价值信息报告给上级，但千万不能透露给基层员工。最理想的状态，就是每名员工都整天坐在自己的计算机前面编写代码，完全不质疑或者挑战现有执行决策。

人力资源部门比人力资源本身更重要

人力资源是种可以牺牲的素材。在危机时刻，公司可以随时剔除某些个体，再快速招聘新的人员。但是，人力资源部门本身却不可替代——他们掌握着招聘与解雇的生杀大权，千万别得罪这帮人。

5 小结

现实中，有着官僚习气的企业要远比灵活有趣的公司数量多得多。大家不妨对号入座思考一下，一旦你发现你的企业或你的项目有这篇文章里提到的问题，就不要抱以希望了，它已经没救了，赶紧撤吧！

原文链接：

https://projectfailures.wordpress.com/