开发12年,整整6百万行代码,史上最烂的开发项目长这样
最近有个史称世界上最烂的开发项目在朋友圈刷屏,这个项目到底有多烂呢?
这个项目拖了整整12年,造出6百万行代码,最后负责人还进*.......
其实这个项目发生在十年前,当时科技博主projectfailures发表过一篇博文,讲述自己亲身经历过的一项“地狱级”的项目
十年后,这件事突然在美国的社交媒体上再次被翻出来,projectfailures也发了一篇名为“地狱级项目”的后续的博客,下面我们一起来看看这个“地狱级项目”到底有多可怕
这个“地狱项目”长这样:
● 600 万行C++代码
● 50,000多个类
● 代码中使用的C++方法早已过时,而且受限于一个编译器版本,该编译器版本仅支持一个不再维护的操作系统。
● 基于CORBA
● 采用一家倒闭公司提供的数据库软件
● 多层的叠加共同组成了用户界面,但却没有一个是实际作者在维护的。
● 在32台并行的机器上编译需要48小时。
● 运行一个用户界面需要同步启动40~50个子进程
● 没有动态库链接:可执行的文件大小一个就有几百兆
● 启动时间需要耗费15分钟
● 平均崩溃时间:30秒到30分钟不等
“地狱级项目”怎么来的
大约在1996年,法国*机构想要开发一款软件,复杂程度不高,然而过程却有些曲折:
当时,*预付了几百万欧元,计划开发周期为2~3年。该公司立马就聘用了几个开发人员来开始这项工作,并且随着资金的不断流入,开发团队的规模每3个月左右就会扩大一倍。
7年过去了,这个项目竟然还没成型,由于工程延误,公司每天要缴交的罚金高达几千欧元。于是,管理层为了降低成本,决定把所有有经验的开发人员都开除了,然后雇佣一些压根没有编程经验的新手进来接盘
10年后,这个项目依然深陷泥潭,这时中层管理人员终于醒悟,决定再聘请一些具有软件工程经验的人员,让项目重回正轨;然而,招进来的工程师基本3个月就待不下去了(法国法定入职后最短可离职时间是3个月)。
12年后,该项目还在苟延残喘。该公司通过向*提交越来越多的项目变更请求来弥补每天的处罚。一晃这都到2008年了
然后又过了几年,这个项目老板据说就因为欺诈而被关进*了,这个“地狱项目”总算结束了
项目烂成这样是有原因的
1、项目采用C++开发
首先,这个项目采用C++开发,没有哪一个程序员敢和你说你C ++是一种简单的语言。实际上,就复杂性而言,C++可能是最糟糕的计算机语言之一。复杂到什么程度呢?复杂到就连他的创造者都承认自己还没有完全掌握这门语言
这个项目选择用C++开发,也不能说是团队的错,要怪就怪当时人们都听说过C ++,并且都自认为自己完全掌握它了。于是毫不犹豫的选择了它,最后耗费了大量的时间不说,程序还无休止地崩溃。
聪明的人,在接触C++之后,果断就转向其他语言了,毕竟人生苦短呐~
再者,无论你选择何种语言开发,维护这么庞大的一个代码库本就是一项艰巨的任务,想象一下,一个团队必须维护600多万行代码,这在软件领域是多么疯狂的一件事。600多万行的代码是什么概念?就算你以每秒一行的速度读取代码,需要不眠不休70天才能把这些代码读完
再来看看下面这两个例子,相信你会更加深有体会:
当时,一位开发人员负责修复一个“在界面单击右键单击会导致整个应用程序冻结”的Bug。经过几天的耐心仔细的检查后,他发现右键单击并不会导致程序异常,只不过右键单击到弹出菜单栏这个过程需要45分钟。每次右键单击主窗口时,菜单都是从一个庞大的内容库中动态生成
还有用户会反映“从CD-ROM加载数据失败”。程序员花了好几个礼拜的时间测试这个Bug,最终啥也没做就直接把Bug标记为“已解决”,因为从CD-RO 载入数据的功能其实没毛病。唯一问题就是加载这700M的数据,需要花7天的时间。
不得不说,耐心真是一种美德。
2、粗犷的版本控制
难以想象,这个项目进行了好几年以后,团队中才有人提出了使用版本控制工具的想法。而且第一次的尝试并不是很满意,因此团队就切换到了另一个系统,然后在几年之后,这个版本控制系统不明原因地每次更改都会丢失所有历史记录,于是,团队又换到了另一个系统。
最终选择的版本控制系统简直就是个灾难,它从瑞典进口,带有图形用户界面,当时还专门组建了一个由四个人组成的团队负责在版本控制软件上处理大多数维护问题,其中包括如下内容:
● 首次提交需要与版本控制团队预约,通常在一周后批准。
● 首次checkout需要向版本控制团队申请,通常在一周后才能获得授权。
● 未经中层管理人员授权,不得编辑文件。你必须提前告知您的经理你要编辑哪些文件,然后发送请求给版本控制团队,该请求也需要几天时间才能得到反馈信息。
● 代码的每次修改都会触发分支,这意味着你必须合并所有修改。你可能会认为存储了这么多文件,两个人改到同一个文件里的几率应该不大,然而事实证明,大多数改动都集中在那100个左右的文件里。
● Checkin(提交修改)仍需要经历一个痛苦的过程,这个过程里,你的代码需要经过一个自动化的Bug检测软件的检测,最终还要由中层管理人员审查你的代码。毋庸置疑,这样做并不能减少程序的Bug数量。更夸张的是检查数据发现,每一个修复完一个Bug都会换来两个新的Bug。
● 版本控制太过简单。旧软件是版本1,今天的软件是版本2,未来的软件是版本3,没有人能够确切地知道哪个版本已经交付给客户。
虽然有时候也会制定一个交付计划,但是计划的这个时间点完全不考虑团队的工作进程。当交付的日子来临时,客户就会收到一张名为安装教程的空白CD,因为没有人能够在几周内构建软件。等到客户发现自己收到的只是一张空白的CD,就会投诉,为了应付了事,团队就会再发送一个旧版的CD。那客户又是怎么发现这张CD是旧版本的呢?因为关于软件介绍的日期显示的和去年那个版本一模一样。
3、乱七八糟的团队
团队中55人:20名开发人员,35名经理。是的,你没有看错,管理人员比开发人员还要多
管理人员不断组织会议,不厌其烦地展示相同的PPT文件,而开发人员则在开放式的办公室里面打发时间,毕竟这35名经理里面没几个有软件工程方面的经验。
当时恰逢SCO起诉IBM滥用Linux版权。即使整个事情是虚张声势,但它确实对这些人起到一定的作用,他们都意识到可能需要为*软件付费了。
他们都没有提到“*软件”,但他们都知道“免费软件”。这个项目到处使用GNU库,并且完全没有意识到这会把整个项目变成一个巨大的、不兼容的GNU项目。但是,考虑到这个项目真的很糟糕,没有人会坚持要他们发布源代码。
还有一个很致命的问题就是技术知识相当薄弱,几乎没人知道互联网,少数几个知道的人,认为互联网就是为色情而生的东西。当问及在互联网上看到的东西时,他只会给你一个微笑,你自己体会
如果这些最高管理层没有像纳粹一样,那么上面这整个经历可能会很有趣。举几个例子让你看看有多变态:
● 禁止超过九点打卡。有一天,经理早早就在大门后面等,当场解雇九点一分以后进来的人,包括一些经理和销售人员。
●管理者试图强制所有人停止吸烟,因吸烟的人在工作的时候,时不时可能就得来一根。
● 因为喝咖啡的人效率低于不喝咖啡一心敲代码的人,所以,每当领导前来视察的时候,咖啡机就会被关闭,给领导留一个每一个人都在努力工作的印象。
● 厕所绝对是你从未见过的那种恶心。想来这可能也是管理层为了避免员工在厕所蹲太久,从而多挤出一点工作的时间
你可能想知道为什么这样的工作环境竟然还有人为他们工作。最主要原因还是当时法国正经历着经济危机,当时的人们有工作有钱拿就不错了,谁还会考虑工作环境。
另一个原因是,对于许多人来说,这份工作可能是他们的第一份工作,没有对比,就没有伤害啊,初入社会的工作者甚至还以为九点过后打卡的人被开除是理所应当的。
至于*如何会让这些事情发生呢?我们都清楚它的运作模式。负责预算的人很多都是公司的高层管理人员。在法国这样的国家,这种的腐败并不罕见,只是大多未被发现,很少被起诉。而且这样的情况也不只是法国才有。在欧洲和美国也有类似的事情。
不过,好在几年后,听说负责这个项目的负责人因为欺诈罪被捕,进了*,这个地狱般的项目,才终于宣告终止。
这位博主长篇大论说了这么多,主要是想告诉我们以下几点:
● C++有风险,选择需谨慎
● CORBA就应该被淘汰
● 采用面向对象的数据库是一个非常糟糕的做法
● 最后,远离贪得无厌的项目管理者
最后,我想说的是如果你觉得你现在的项目真是糟糕透了,不妨想想这个项目……
转载地址:https://blog.csdn.net/h8y0bdjvukwe1lbozle/article/details/81091525