史上最烂的项目：苦撑12年，600多万行代码...
|
每次对文件的修改都会触发分支，这就意味着你得自己去合并这个文件收到的所有修改。也许你会觉得，项目里这么多文件，两个人改到同一个文件里的几率应该不大，然而实际上，绝大多数改动都集中在同样的大概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 的博主给刚踏入编程世界的年轻人的建议是：
最后，如果你觉得你现在的工作很糟心很窝火，希望这个项目能让你开心一点。 【编辑推荐】
点赞 0 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
