转自:Cado - 36kr

  36kr.com/p/5130755.html

  【编者按】:很多软件项目开发时间大大超出了规划的时间,投入大量资金和人力,都没有实在的结果。如果你讨厌你的编程工作,请认真阅读这篇 2008 年的文章吧。法国科技公司为政府做的项目,预期两三年,做了十二年还在做;6 百万行 C++ 代码,经理比工程师多,人员素质极低。

  

500303795_wx.jpg


  几年前,我在一家法国大型科技公司工作,为他们的一个软件项目做咨询师。在那段时间,我见识到了软件工程工作方面最匪夷所思的一切,完全超乎我的想象。项目人员工作极度不专业,而更严重的是,工作环境完全无视人的尊严。我一度觉得去那里上班就像坐牢。我只要举几个例子,读者自然就有分晓。

  工作内容

  为一个政府部门开发一款软件。

  政府先付了几百万欧元的订金,软件开发耗时初定 2 到 3 年。公司雇了几个工程师,开始了项目。每隔三个月,团队人数就翻一番,以便让资金不断流入。

  7 年后,项目还不成样子,连雏形都没有。每天公司都要交几千欧元的罚金。于是,管理层决定节流,把经验丰富的员工都辞退了,雇了些经验少,甚至完全没经验的新人。

  10 年后,项目进度实在太滞后,中层管理人员决定雇佣有软件工程经验的人,把项目拉回正轨。公司的员工每三个月换一批,也就是法国离职交接期的时长。

  12 年后,项目还没结束。公司每天给政府发的修改申请越来越多,以“补贴”每天缴纳的罚金。此时已经是 2008 年。

  项目数据

  •   600 万行代码

  •   基于 C ++

  •   50,000+ 类

  •   使用的 C ++ 已经过时,“锁死”在编译器版本中,编译器的版本只能一个操作系统上用。

  •   基于 CORBA

  •   项目使用的数据库软件背后的公司已经破产

  •   图层用户界面有好几个,但实际上每一层都没人维护。

  •   32 台计算机上构建,需要 48 小时

  •   运行一个用户界面需要 40 到 50 个并行进程

  •   没有动态库链接:可执行文件大小在数百兆字节范围内

  •   启动时间约为 15 分钟

  •   瘫痪频率:每 30 秒到 30 分钟一次

  没有那个软件工程师会说 C++ 很简单。就其复杂程度而言,这或许是最难掌握的编程语言,就连创造 C++ 的几个工程师都坦白说,他们自己也没有完全掌握。

  这种无底洞、大迷宫似的语言,还是有不少人扬言说自己已经掌握了,只要有机会,他们就敢用给你看。他们一猛子扎进这口深井,最后大多遍体鳞伤。看着一满篇天书,花不知多少小时,也找不到瘫痪原因。人都是很聪明的,人生短暂,投入一段时间没有回报,就会“弃暗投明”,改用其他语言,改做其他项目。

  软件一大,不管是什么语言写的,维护起来都很难。6 百万行代码,就一个小团队维护,只要想想就能发疯。6 百万可不是小数字,就算一秒钟读一行,也要 70 天不眠不休才能看完。

  我再举两个实例,读者就知道这个项目有多让人崩溃。

  有一个开发者被分配了这样一个任务:找出在界面上点击右键,界面冻结的原因。他花了几天时间,仔仔细细检查,耗掉大半耐心之后,他发现,在界面上右击后,其实没有错误,只是内容菜单要 45 分钟后才弹出。每次用户在主窗体点击后,菜单是动态生成的,但是背后是巨量的静态内容,因此耗时长。有些用户反馈说“加载 CD”的命令完全没反应。这个问题花了几个星期才弄明白,但是最后,错误报告却被标记为“已解决”,因为数据确实有加载,只不过是花了整整 7 天,才加载完 700 兆的数据。嗯,不然怎么说耐心是美德呢…

  


  版本控制,犹如脱缰野马

  好几年过去了,团队里终于来了个人才,提出要用版本控制工具。第一次尝试,效果不如人意,于是团队决定换一个系统。又过了几年,每次更新的历史数据全没了。最后,他们选择使用一个瑞士的系统,图形用户界面简直不堪入目。有一个四人小组全职负责版本控制软件方面的维护问题,跟他们合作,我们常常面临以下的问题:

  •   第一次测试需要与版本控制团队先预约时间,通常在一周后才授权。

  •   未经中层管理人员授权,不允许编辑文件。必须事先告诉经理要编辑哪些文件,然后申请上级许可,再预约版本控制团队,在几天后才能编辑。

  •   每次修改代码都会产生分支文件,也就意味着必须合并所有修改。有了这么多的文件,你可能觉得,不会出现两个人弄同一个文件上的重复劳动。但事实证明,大家都在弄同样的 100 个文件。

  •   检入(check in)过程非常痛苦,这个过程中,你的代码经过自动化错误检测软件审查,最终由中间管理人员审查。不用说,bug 的出现速度永远比开发人员纠正速度快得多。如果你仔细看注册的错误数量,每次修正导致的新 bug 数量,是原来 bug 数量的两倍。

  •   版本控制很简单。旧软件是版本1,目前的软件是版本2,未来的软件是版本 3. 没有人知道哪个版本已经交付给客户了。

  从前的某一天,公司安排过正式交付。但是这个时间不是团队内的人定的。那天,客户受到了一张没有内容,只有安装指引的光盘。那时因为,没有人知道怎么把这个项目做出来。后来客户发现他们受到的光盘里,什么也没有,于是给公司发了封正式的投诉信。

  公司居然把旧版本的软件发给了客户。客户之所以能发现,是因为他们看了“说明”栏,里面的内容跟上一年的版本大同小异。

  “人件”

  微薄薪水,只能雇庸碌之辈

  团队里大部分人都是没有软件工程经验的人,软件里要不是大部分都是 bug,就奇了怪了。经理意识到,一个单纯的软件项目,支出的大头是薪水,真是天资聪颖。但是,这个大发现丝毫没有影响 TA 炒掉工程师,不论他们有没有经验,却把桌面上有“C++傻瓜入门”之类书的管理人员统统留下了。

  我们的梦想团队

  团队 55 人:20 个开发者,35 个管理人员

  没错,管理人员数量比工程师还多。

  管理人员最擅长的就是开会,讲的都是同一个 PPT,一遍又一遍,讲到吐为止。而开发者就在宽敞的共用办公空间里聊天解闷。

  很多管理人员在软件工程上毫无经验。当时 SCO-Linux 争议炒得沸沸扬扬,不管整件事算不算闹剧,很多人都意识到,以后要用自由软件都要付费了。)不用说,整个软件到处都是 GNU C 库里的代码,一个巨型 GNU 兼容的非共享软件。但是,就这个项目的水准,估计也没人敢把代码放出去。


  自由软件(free software),根据自由软件基金会对其的定义,是一类可以不受限制地自由使用、复制、研究、修改和分发的,尊重用户自由的软件。这方面的不受限制正是自由软件最重要的本质,与自由软件相对的是专有软件(proprietary software),或被称为私有软件、封闭软件(其定义与是否收取费用无关──自由软件不一定是免费软件。

  整个团队,技术水平不如人意,了解互联网的人屈指可数,其中自认为了解互联网的,以为互联网只是为爱情动作片而生的。他们之间,如果有人说自己在网上看了点东西,听者就会露出会心一笑。

  地狱之旅

  本来在这里的工作,虽然不算优越,至少不会无聊。但是顶层的管理人员非要采用纳粹管理集中营的办法来管理员工。我随便举几个例子:

  •   早九点后到岗是不允许的。有一天, 经理站在大门后,把 9 点整以后到的所有员工都当场炒鱿鱼,包括一些经理和销售人员。

  •   抽烟的员工,因为跑出去抽烟,工作的时间就打了折扣。所以管理层决定让所有员工都不许吸烟。当然,没有用。

  •   有时候,一连好几天咖啡机都被收起来。因为跑去喝咖啡的人自然没有坐在办公桌前的人、伏案写代码的人工作时间长。

  •   每次有上级来视察,咖啡机就要关掉,以便给上级留下大家都在桌前认真写代码的印象。

  •   那里的洗手间是我去过的洗手间里最恶心的。大概也是为了提高大家的效率:上厕所的时间少了,工作的时间自然就多了(工作质量自然也上去了)。

  这样的工作,这样的管理,为什么大家还要来上班?最主要的原因就是当时法国深陷经济危机(某种程度上,现在也是),有工作,有薪水几乎成了特权,工作环境、内容自然就没那么在意了。

  还有一个原因,对于在那里的大多数员工而言,这份合约算是他们与一家真实公司签下的一份实实在在的合约。没有对比,就没有伤害,他们可能都不知道这份工作的糟心程度。很多员工新入职场,觉得迟到就被炒鱿鱼,也没什么不合理的。但是,这样严苛的标准,晚一分钟都不行,只有变态的管理者才会付诸现实。

  话又说回来,政府怎么会让这样的事情发生呢?但我们都心知肚明,政府里管这个项目预算的官员和软件公司的顶层管理人员拜过把子,关系够铁。在法国,这种程度的腐败也没什么新鲜的。很多人根本不知道,更别说有什么惩罚或者后果了。当然,也不限于法国,放眼欧美,这样的故事也不少。

  所以,下次上班觉得难熬,要学会置身处地。想像一下自己在那里工作,会是什么光景。