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

時間 2019-11-11

標籤史上項目多萬代碼简体版

原文原文鏈接

做者：歐剃程序員

https://juejin.im/post/5bf67d9f6fb9a049d5192042spring

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

到底有多爛？用下面這組觸目驚心的數據告訴你↓↓編程

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

● 總共 50000 多個類併發

● 受編譯器版本限制，用的 C++ 語法都是陳舊過期的，只能在某個（早就沒有維護）的操做系統上部署框架

● 基於 CORBA編程語言

● 採用的數據庫軟件來自一家早就破產的公司編輯器

● 好幾層互相疊加的層共同組成了用戶界面，並且這些層沒有一個是由原做者維護的工具

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

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

● 沒有采用運行庫動態連接技術，一個可執行程序就有好幾百兆那麼大

● 啓動這玩意大約須要 15 分鐘

● 而後通常 30 秒到 30 分鐘內會崩潰

img

你從未見過的「地獄級」爛項目

十年前的 2008 年，科技博客 projectfailures 爆料，博主那幾年曾受僱於法國的一家大型科技企業，參與過一個政府機構委託的軟件項目，職位是諮詢顧問。在那裏，他親眼見證了登峯造極的愚蠢和瘋狂，以及它們在軟件開發工做中起到的可怕做用。

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

在文章中，他這樣寫到：「這已經不只僅是什麼缺少專業能力的問題了，這個項目中對人類尊嚴的無情踐踏，已經嚴重到有的時候讓我感受置身於監獄之中。」

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

這項目到底啥狀況？

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

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

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

項目開始10年後，整個項目已經深陷在災難的泥潭中，徹底是由純粹的混亂所組成。因而項目的中層管理者終於決定要招一些具備軟件工程開發經驗的人，來把這個爛攤子從地獄裏拖出來。

又過了兩年，這項目竟然還在苟延殘喘。這公司經過給甲方發送金額不斷提升的「設計變動」帳單，來彌補天天產生的工期延誤罰金。這都 2008 年了喂！

這項目怎麼能爛成這樣？

01 代碼質量慘不忍睹

在語言選擇方面，沒人敢說 C++ 是種簡明易懂的語言。事實上，在簡潔方面，C++可能算是最糟糕的一種編程語言了吧。要知道，它但是複雜到連它的創造者 Bjarne Stroustrup 本人都不敢說本身徹底掌握了這門語言。

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

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

不過，看起來，這家公司並無跳出這個圈子，仍是一個猛子扎進了 C++ 坑裏。

退一步說，無論你用的是什麼編程語言，維護一個巨大的代碼庫自己就不是一件容易的事情——而這個項目的代碼庫竟然有 600 多萬行之巨。

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

對比下 Linux 3.13 版內核的代碼，在除去內核驅動和架構以外，在 kernel/ 裏的源代碼也不過就 13 萬行左右；另外一個例子是著名的編輯器 Emacs，它由於功能太多太龐大，常被人吐槽成「缺少一個好編輯器的操做系統」，但即便如此，它的總源碼規模也不過就是 165 萬 9 千多行。

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

因而咱們能夠想見，維護這麼大一個代碼庫，可得逼瘋多少程序員呢。看看下面這兩個例子，我想，若是我是程序員的話，我也會先瘋爲敬吧。

有一次，項目裏的一個程序員被要求修復一個「右鍵點擊界面會致使整個應用卡死」的 bug，通過連續幾天的仔細檢查，消耗無數耐心以後，他發現，這個右鍵響應事件其實工做的很正常，只不過這個「正常」過程須要程序花上 45 分鐘，從某種巨大的（靜態！）內容庫中動態生成每個菜單項，而後才能把菜單給顯示出來。若是這時候你不幸又點了一下右鍵，很差意思，咱再花 45 分鐘從新生成一下菜單項吧…

還有一次，用戶報了個「從 CD-ROM 載入數據失敗」的 bug 。程序員們花了好幾個星期來測試分析代碼，最後卻直接把這個 issue 標成了「已解決」。由於他們發現，從 CD-ROM 載入數據的功能實際上是好的，問題在於，讀取 700MB 的數據，這程序要花上大概 7 天時間罷了。

還真是特別考驗耐心呀。

02 版本控制全都是亂來

使人難以置信的是，這團隊在徹底沒有版本控制工具的狀況下也搞了好幾年，直到團隊裏一個腦子還算清醒的傢伙忽然想到該用個版本控制工具來管理代碼。剛開始的嘗試結果並無讓全部人滿意，因此這個團隊就換到了另一個版本控制系統。就這麼將就了一兩年，而後這個版本控制系統不知怎麼又抽了個風，把以前全部改動的記錄都丟失了。

最後這個項目選定的版本控制工具，是一團帶有圖形用戶界面的禍害，一坨從瑞典直接進口的數字化電子垃圾。他們不得不安排了4我的組成一個「版本控制團隊」，全職負責維護這個版本控制系統的正常運行。而這直接致使下列狀況的出現：

首次從版本控制系統中檢出文件須要向版本控制團隊預定，通常來講在一週後才能得到受權。
想修改文件必須通過中層管理人員審批。你須要提早列出須要修改的文件，把列表告訴你的經理，而後打報告給版本控制團隊申請，後者大概兩天左右會給你反饋。
每次對文件的修改都會觸發分支，這就意味着你得本身去合併這個文件收到的全部修改。也許你會以爲，項目裏這麼多文件，兩我的改到同一個文件裏的概率應該不大，然而實際上，絕大多數改動都集中在一樣的大概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 的博主給剛踏入編程世界的年輕人的建議是：

● 珍愛生命，沒事別用 C++ 折騰本身；

● 寧願接一些不那麼穩定，但能自由發揮所長的小項目，也別貪圖安逸去參加什麼看起來很堂而皇之的工程；

● 面向對象的數據庫並非什麼好東西；

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

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

最後，若是你以爲你如今的工做很糟心很窩火，但願這個項目能讓你開心一點。