史上最爛的項目：苦撐 12 年，600 多萬行代碼

·????? 這項目到底啥情況？

·????? 這項目怎么能爛成這樣？

·????? 那，600 多萬行代碼是個什么概念？

·????? 不可避免的結局

你見過最爛的項目，撐了多長時間才完蛋？六個月？一年？今天介紹的這個奇葩項目，不但一開始就爛得透透的，還硬撐了12年多，直到項目負責人被逮起來丟進監(jiān)獄才完事。

到底有多爛？用下面這組觸目驚心的數(shù)據告訴你↓↓

● 總共 600 多萬行 C++ 代碼

● 總共 50000 多個類

● 受編譯器版本限制，用的 C++ 語法都是陳舊過時的，只能在某個（早就沒有維護）的操作系統(tǒng)上部署

● 基于 CORBA

● 采用的數(shù)據庫軟件來自一家早就破產的公司

● 運行一個用戶界面需要啟動 40-50 個子線程

● 在 32 臺并行的機器上需要 48 小時進行編譯

● 沒有采用運行庫動態(tài)鏈接技術，一個可執(zhí)行程序就有好幾百兆那么大

● 啟動這玩意大約需要 15 分鐘

● 然后一般 30 秒到 30 分鐘內會崩潰

你從未見過的“地獄級”爛項目

十年前的 2008 年，科技博客 projectfailures 爆料，博主那幾年曾受雇于法國的一家大型科技企業(yè)，參與過一個政府機構委托的軟件項目，職位是咨詢顧問。在那里，他親眼見證了登峰造極的愚蠢和瘋狂，以及它們在軟件開發(fā)工作中起到的可怕作用。

十年過去了，這個地獄般的項目又被人翻了出來，再次炒的沸沸揚揚，而 projectfailures 博客甚至還就此專門出了一篇回顧。

在文章中，他這樣寫到：“這已經不僅僅是什么缺乏專業(yè)能力的問題了，這個項目中對人類尊嚴的無情踐踏，已經嚴重到有的時候讓我感覺置身于監(jiān)獄之中。”

啥啥啥？不過是寫點代碼而已，除了賠上頭發(fā)，難道會連命都搭進去嗎！？這個項目咋這么恐怖啊！

這項目到底啥情況？

大約是 1996 年，法國的一個政府機構請某個公司開發(fā)一款軟件。總的來說這玩意應該不太復雜，只不過有一些不太尋常的小問題需要解決罷了。

甲方預付了幾百萬歐元，計劃工期大概2～3年左右。于是公司招了幾個程序員，開始干活。隨著資金陸續(xù)到位，這公司開始瘋狂招人，每隔三個月左右就把隊伍擴大一倍。

結果，7年過去了，這個項目根本還不成型。因為延誤造成的罰金每天都達幾千歐元。于是管理層決定，要精簡一下團隊，減少項目開支 —— 具體做法是，把干活的人都開了，另外招一些對軟件開發(fā)沒啥經驗的新手來上班。

項目開始10年后，整個項目已經深陷在災難的泥潭中，完全是由純粹的混亂所組成。于是項目的中層管理者終于決定要招一些具有軟件工程開發(fā)經驗的人，來把這個爛攤子從地獄里拖出來。

又過了兩年，這項目居然還在茍延殘喘。這公司通過給甲方發(fā)送金額不斷提高的“設計變更”賬單，來彌補每天產生的工期延誤罰金。這都 2008 年了喂！

這項目怎么能爛成這樣？

01 代碼質量慘不忍睹

在語言選擇方面，沒人敢說 C++ 是種簡明易懂的語言。事實上，在簡潔方面，C++可能算是最糟糕的一種編程語言了吧。要知道，它可是復雜到連它的創(chuàng)造者 Bjarne Stroustrup 本人都不敢說自己完全掌握了這門語言。

當然，這不能全怪開發(fā)團隊。要知道，在當時，像 C++ 這樣擁有無盡復雜度的思維迷宮還是大有市場的。許多希望成為超級程序員的年輕人都對這門聽起來超牛逼的語言趨之若鶩。而事實上，這些可憐的娃們，最后大部分都被 C++ 虐慘了，多少美好的青春，都耗費在反復調試一大段晦澀難懂的代碼，耗費在探尋為啥這程序會毫無理由莫名崩潰這樣的事情上了。

而腦子正常的人，則紛紛轉向了其他語言和其他項目上去了。要知道，人生苦短啊。

不過，看起來，這家公司并沒有跳出這個圈子，還是一個猛子扎進了 C++ 坑里。

退一步說，不管你用的是什么編程語言，維護一個巨大的代碼庫本身就不是一件容易的事情——而這個項目的代碼庫居然有 600 多萬行之巨。

那，600 多萬行代碼是個什么概念？

對比下 Linux 3.13 版內核的代碼，在除去內核驅動和架構之外，在 kernel/ 里的源代碼也不過就 13 萬行左右；另一個例子是著名的編輯器 Emacs，它因為功能太多太龐大，常被人吐槽成“缺乏一個好編輯器的操作系統(tǒng)”，但即使如此，它的總源碼規(guī)模也不過就是 165 萬 9 千多行。

就算你特別厲害，一目十行，你大概也要在顯示器前面不眠不休花上7天，才能把全部 600 萬行代碼全部過一遍。

于是我們可以想見，維護這么大一個代碼庫，可得逼瘋多少程序員呢。看看下面這兩個例子，我想，如果我是程序員的話，我也會先瘋為敬吧。

有一次，項目里的一個程序員被要求修復一個“右鍵點擊界面會導致整個應用卡死”的 bug，經過連續(xù)幾天的仔細檢查，消耗無數(shù)耐心之后，他發(fā)現(xiàn)，這個右鍵響應事件其實工作的很正常，只不過這個“正常”過程需要程序花上 45 分鐘，從某種巨大的（靜態(tài)！）內容庫中動態(tài)生成每一個菜單項，然后才能把菜單給顯示出來。如果這時候你不幸又點了一下右鍵，不好意思，咱再花 45 分鐘重新生成一下菜單項吧…

還有一次，用戶報了個“從 CD-ROM 載入數(shù)據失敗”的 bug 。程序員們花了好幾個星期來測試分析代碼，最后卻直接把這個 issue 標成了“已解決”。因為他們發(fā)現(xiàn)，從 CD-ROM 載入數(shù)據的功能其實是好的，問題在于，讀取 700MB 的數(shù)據，這程序要花上大概 7 天時間罷了。

還真是特別考驗耐心呀。

02 版本控制全都是亂來

令人難以置信的是，這團隊在完全沒有版本控制工具的情況下也搞了好幾年，直到團隊里一個腦子還算清醒的家伙突然想到該用個版本控制工具來管理代碼。剛開始的嘗試結果并沒有讓所有人滿意，所以這個團隊就換到了另外一個版本控制系統(tǒng)。就這么將就了一兩年，然后這個版本控制系統(tǒng)不知怎么又抽了個風，把之前所有改動的記錄都丟失了。

最后這個項目選定的版本控制工具，是一團帶有圖形用戶界面的禍害，一坨從瑞典直接進口的數(shù)字化電子垃圾。他們不得不安排了4個人組成一個“版本控制團隊”，全職負責維護這個版本控制系統(tǒng)的正常運行。而這直接導致下列情況的出現(xiàn)：

·????? 首次從版本控制系統(tǒng)中檢出文件需要向版本控制團隊預約，一般來說在一周后才能獲得授權。

·????? 想修改文件必須經過中層管理人員審批。你需要提前列出需要修改的文件，把列表告訴你的經理，然后打報告給版本控制團隊申請，后者大概兩天左右會給你反饋。

·????? 每次對文件的修改都會觸發(fā)分支，這就意味著你得自己去合并這個文件收到的所有修改。也許你會覺得，項目里這么多文件，兩個人改到同一個文件里的幾率應該不大，然而實際上，絕大多數(shù)改動都集中在同樣的大概100來個文件里，所以每次 merge 都保證讓你痛不欲生。

·????? 在提交修改（檢入文件）之前，你還將經受一次精神折磨：你準備提交的代碼將被交給一個所謂的自動 bug 探測程序進行審閱，通過之后還要拿給中層管理人員看過，才能成功提交。不用說，這根本無濟于事，bug 還是如雨后春筍一樣不停冒尖，比大家除 bug 的速度塊多了。更有甚者，對發(fā)現(xiàn)的 bug 數(shù)量進行分析后發(fā)現(xiàn)，這種“缺陷修正”方式帶來的新 bug 數(shù)量是它所修復的 bug 數(shù)量的兩倍…

·????? 版本管理過于簡單。舊的版本是 1，今天的版本是 2，之后的版本是 3。沒有人能確切地知道具體發(fā)給客戶的是哪個版本。

某些時候，管理層會定下一個所謂的官方交付時間，而這個時間安排跟團隊中的任何一種工作計劃都毫無關系。當預定的交付日期到來的時候，客戶實際上收到的是一張帶有安裝教程的……空白CD，因為已經有好幾個星期沒有人能構建可執(zhí)行程序了。于是，客戶發(fā)現(xiàn)自己收到的是空白光盤，然后正式投訴，然后收到一個舊版的程序光盤作為應付。而客戶之所以會發(fā)現(xiàn)程序是舊版的，是因為軟件的“關于”頁上還寫著跟去年那個版本一模一樣的日期…

03 團隊組成更是莫名其妙

團隊里充斥著這么一大群毫無任何軟件工程經驗的人，這軟件里要是 bug 不多就還真沒天理了吧？

還記得上面提到過，管理層曾經決定，要精簡一下團隊的事吧。

按理說，任何一個腦筋正常的經理都會發(fā)現(xiàn)，對于這樣一個純軟件工程的項目來說，人員開支必定是最主要的開支。然而，這個發(fā)現(xiàn)，并不能阻止管理層把所有稍微有點經驗的程序員都開了，換上對工資要求低得多的菜鳥。相對的，所有的經理們的飯碗倒是都捧得牢牢的，一點都沒受影響。

這團隊后來變成什么樣了呢？55 個人里面，只有 20 個程序員，剩下 35 個都是經理。對，你沒有看錯，這個陣容真是豪華，給每個程序員配備了 1.75 個經理！

沒幾個經理有軟件工程方面的經驗。那時候，剛好出了 SCO 拿著 Unix 版權起訴 Linux 用戶的事情，就算這整件事不過是虛張聲勢，但對許多人來說，當時這事還是挺可怕的 —— 要是突然有天你不得不為自由軟件付費，那可如何是好啊。

技術知識也相當缺乏。都 200x 年了，這群人還沒幾個了解互聯(lián)網的，少數(shù)幾個熟悉互聯(lián)網的，也不過就是拿互聯(lián)網看看小電影而已。要是你提到你在網上看了些啥，得到的都只會是別人的竊笑而已。

04 行政管理模式變態(tài)的發(fā)指

上面的荒謬情況也許會讓人捧腹大笑，但如果你知道管理層的那群法國佬對員工發(fā)起狠來就像是奧斯維辛集中營里的德國鬼子，那你估計就笑不出來了吧。來看看這些官僚到病態(tài)的規(guī)定吧：

·????? 禁止遲到，所有人必須在上午9點前到崗。有一天，人事經理早早就守在公司大門口，把所有9點01分及之后才到公司的人都當場開除了，程序員、經理和銷售，都不能幸免。

·????? 咖啡機時不時就斷供，一斷就是好幾天。理由當然是跑去喝咖啡的人效率不如坐著干活敲代碼的人。不僅如此，每當有領導來開發(fā)部視察的時候，這臺咖啡機還會被人關掉，免得讓領導看到有人“沒在干活”。

·????? 廁所的臟亂差程度可以說是業(yè)內絕無僅有的惡心與恐怖。想來這也是管理層避免大家花時間蹲帶薪廁的“高效”政策使然吧。

你可能要問了，這種變態(tài)公司，怎么還有人前仆后繼的來上班？最主要的是，那段時間法國國內經濟正在崩潰的邊緣掙扎（直到現(xiàn)在，法國還沒完全走出這個泥潭），能找到一份足以糊口的工作就已實屬不易，工作條件苛刻點也就算了。

不可避免的結局

正如網友評論的那樣，著整個項目陷入了死循環(huán)的鏈條之中：缺乏經驗導致低效，低效導致開銷太大，節(jié)省開銷又裁掉有經驗的人，進一步降低效率。

那么，為什么管理層還坐視這種情況的不斷惡化呢？歸根結底還是對失敗的擔心。如果你砍掉這個項目，就意味著這個項目失敗了，而負有領導責任的人就是你。如果這項目還在茍延殘喘，那等你升遷調任之后，這個爛攤子自然由繼任者來收拾啦。

最終，負責這個項目的公司領導因為挪用資金等原因被捕，進了監(jiān)獄，這個在地獄的烈焰中掙扎了十幾年的項目，才終于宣告終止。

作為整件事情的親歷者，projectfailures 的博主給剛踏入編程世界的年輕人的建議是：

● 珍愛生命，沒事別用 C++ 折騰自己；

● 寧愿接一些不那么穩(wěn)定，但能自由發(fā)揮所長的小項目，也別貪圖安逸去參加什么看起來很冠冕堂皇的工程；

● 面向對象的數(shù)據庫并不是什么好東西；

● CORBA 應該在烈焰中痛苦的死去；

● 那些愚蠢的產品經理，請參照上一條。

最后，如果你覺得你現(xiàn)在的工作很糟心很窩火，希望這個項目能讓你開心一點。

方志朋簡介：SpringCloud?中國社區(qū)聯(lián)合創(chuàng)始人，博客訪問量突破一千萬，愛好開源，熱愛分享，活躍于各大社區(qū)，保持著非常強的學習驅動力，終身學習踐行者，終身學習受益者。目前就職于國內某家知名互聯(lián)網保險公司，擔任DEVOPS?工程師，對微服務領域和持續(xù)集成領域研究較深，精通微服務框架SpringCloud。

C++ 開發(fā)者

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。