開發12年 整整6百萬行代碼：史上最爛的開發項目長這樣

來自專欄我為科技狂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://projectfailures.wordpress.com

推薦閱讀：