史上最烂的项目：苦撑12年，600多万行代码...
|
副标题[/!--empirenews.page--]
你见过最烂的项目，撑了多长时间才完蛋?六个月?一年?今天介绍的这个奇葩项目，不但一开始就烂得透透的，还硬撑了12年多，直到项目负责人被逮起来丢进监狱才完事。 到底有多烂?用下面这组触目惊心的数据告诉你↓↓
你从未见过的“地狱级”烂项目 十一年前的 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个人组成一个“版本控制团队”，全职负责维护这个版本控制系统的正常运行。而这直接导致下列情况的出现： 首次从版本控制系统中检出文件需要向版本控制团队预约，一般来说在一周后才能获得授权。 想修改文件必须经过中层管理人员审批。你需要提前列出需要修改的文件，把列表告诉你的经理，然后打报告给版本控制团队申请，后者大概两天左右会给你反馈。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
