史上最烂的开发项目长啥样:苦撑12年,600多万行代码...
导读:你见过最烂的项目,撑了多长时间才完蛋?六个月?一年?今天介绍的这个奇葩项目,不但一开始就烂得透透的,还硬撑了12年多,直到项目负责人被逮起来丢进监狱才完事。
总共 600 多万行 C++ 代码 总共 50000 多个类 受编译器版本限制,用的 C++ 语法都是陈旧过时的,只能在某个(早就没有维护)的操作系统上部署 基于 CORBA 采用的数据库软件来自一家早就破产的公司 好几层互相叠加的层共同组成了用户界面,而且这些层没有一个是由原作者维护的 运行一个用户界面需要启动 40-50 个子线程 在 32 台并行的机器上需要 48 小时进行编译 没有采用运行库动态链接技术,一个可执行程序就有好几百兆那么大 启动这玩意大约需要 15 分钟 然后一般 30 秒到 30 分钟内会崩溃
在文章中,他这样写到:“这已经不仅仅是什么缺乏专业能力的问题了,这个项目中对人类尊严的无情践踏,已经严重到有的时候让我感觉置身于监狱之中。”
首次从版本控制系统中检出文件需要向版本控制团队预约,一般来说在一周后才能获得授权。
想修改文件必须经过中层管理人员审批。你需要提前列出需要修改的文件,把列表告诉你的经理,然后打报告给版本控制团队申请,后者大概两天左右会给你反馈。
每次对文件的修改都会触发分支,这就意味着你得自己去合并这个文件收到的所有修改。也许你会觉得,项目里这么多文件,两个人改到同一个文件里的几率应该不大,然而实际上,绝大多数改动都集中在同样的大概100来个文件里,所以每次 merge 都保证让你痛不欲生。
在提交修改(检入文件)之前,你还将经受一次精神折磨:你准备提交的代码将被交给一个所谓的自动 bug 探测程序进行审阅,通过之后还要拿给中层管理人员看过,才能成功提交。不用说,这根本无济于事,bug 还是如雨后春笋一样不停冒尖,比大家除 bug 的速度块多了。更有甚者,对发现的 bug 数量进行分析后发现,这种“缺陷修正”方式带来的新 bug 数量是它所修复的 bug 数量的两倍…
版本管理过于简单。旧的版本是 1,今天的版本是 2,之后的版本是 3。没有人能确切地知道具体发给客户的是哪个版本。
禁止迟到,所有人必须在上午9点前到岗。有一天,人事经理早早就守在公司大门口,把所有9点01分及之后才到公司的人都当场开除了,程序员、经理和销售,都不能幸免。 咖啡机时不时就断供,一断就是好几天。理由当然是跑去喝咖啡的人效率不如坐着干活敲代码的人。不仅如此,每当有领导来开发部视察的时候,这台咖啡机还会被人关掉,免得让领导看到有人“没在干活”。
厕所的脏乱差程度可以说是业内绝无仅有的恶心与恐怖。想来这也是管理层避免大家花时间蹲带薪厕的“高效”政策使然吧。
珍爱生命,没事别用 C++ 折腾自己; 宁愿接一些不那么稳定,但能自由发挥所长的小项目,也别贪图安逸去参加什么看起来很冠冕堂皇的工程; 面向对象的数据库并不是什么好东西; CORBA 应该在烈焰中痛苦的死去; 那些愚蠢的产品经理,请参照上一条。
来源:优达学城Udacity(ID:youdaxue)
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
评论