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

最新 07-16

51CTO官微

技術資訊/行業精華/產品心得

程序員（ID：imkuqin）猿妹編譯

原文：https://projectfailures.wordpress.com

最近有個史稱世界上最爛的開發項目在朋友圈刷屏，這個項目到底有多爛呢？

這個項目拖了整整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個月）。

GIF

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是舊版本的呢？因為關於軟體介紹的日期顯示的和去年那個版本一模一樣。