給2500萬行代碼修復bug的程序員都怎麼上班？_風聞

文/世超

通常説，一個人造的、很龐大的事物，會給人很厲害的感覺。

比如説摩天大樓⬇️

或者巨型水壩⬇️

看着這種東西，世超不禁想到這幾個字： “ 人類工程學奇蹟 ” 。

但是欣賞歸欣賞，這種巨型工程項目如果出了啥子問題，不得不維護的話，那這個**維護痛苦程度只能用****“ 災難 ”**來形容了。

世超最近在網上就看到了這樣一個科技界的龐然大物： Oracle Database 12.2 的代碼庫！

在國外計算機論壇 Hacker News 上，有人問了這樣一個問題： “ 你見過的規模最大的還在使用的爛代碼有多大？ ”

一個目測是 Oracle 員工， ID 叫 “ oraguy ” 的用户給出了回答⬇️

甲骨文數據庫 12.2 版本，一個將近 2500 萬行 C 語言代碼的龐然大物！

世超打個比方吧，寫代碼就好比堆積木，一旦整個積木都有了功能之後，隨便動其中任何一塊，都會導致其他積木出事兒，塌了都有可能。。。

這樣巨型項目經手的程序員太多了，每個人都按照自己的方式解決問題，這就導致其他人要在項目之上寫東西的時候，得花大量時間搞懂原來的代碼是怎麼運作的。。。

好在這個代碼庫還有非常完整的測試代碼，出了問題不用讓程序員自己找 BUG 出處。

只不過。。。據 oraguy 説，這個項目改一行代碼之後，一般會跳出 1000 多條測試失敗的消息，然後程序員要一個個排除。。。

也虧得這上百萬項測試，這個項目現在還能商用。

所以給 Oracle Database 寫代碼的程序員，工作流程一般是這樣的⬇️

1. 拿到一個新任務：解決一個新發現的 bug 。

2. 花兩週時間瞭解 20 個不同的 flag （ 標記 ），這些標記用一種很奇怪的方式製造了這個 bug 。

3. 嘗試添加 flag，寫幾行代碼，同時要小心不會製造出更多 bug

4. 提交一下修改過的代碼，然後用測試服務器創造一個新的數據庫，並且跑一下那幾百萬個測試。。。

5. 回家，第二天來的時候做點兒別的，因為測試要跑二三十個小時。

6. 回家，第二天來的時候看看結果：運氣好的話可能只有 100 個測試失敗；運氣不好的話有 1000 個失敗。隨便找個失敗的測試，理解一下這個 bug 的原理。

7. 改一改，提交，測試，再來二三十個小時。。。

8. 重複以上步驟，倆星期後你大概能理解這個 bug 的原因了。

9. 終於，在你幾乎錘蛋自盡之前，發現某次測試完全通過了！

10. 再寫上百個測試，以防下次哪個晦氣孩子要碰項目的時候，不會把你的修改搞砸。。。

11. 提交代碼，做最後一次測試和代碼覆盤，這個過程大約需要花2 周到 2 個月，所以這段時間去修別的 bug 吧！

12. 搞定一切，代碼修改可以添加到產品裏去了！

以上。。。。

而且據 oraguy 説，如果要給數據庫添加一個小功能，往往需要花 6 個月到 1 年的時間。

原因世超想想都知道：可能寫新功能代碼只用花 1 個月，剩下的時間都在改因為新功能產生的 bug 。。。

還記得差評君之前説的技術債麼？ Oracle 的這個 2500 萬行的項目，可能就是負債累累的樣子。。。

會變成這樣的原因。。。就是每個人幹活都沒啥規範，碰到問題修修補補就好，完全沒有考慮整個項目。

事實上，如果遵守一些代碼規範的話，就不會這麼糟糕。

世超的同事裏有個前華為員工，説他們組的大項目也有上千萬行代碼，修改 bug 或者添加功能的週期只有數週。

所以説。。災難可能都是遭難的人當初一手造出來的。。。

圖片來源：

Construction Specifier

Travel Nevada

Drupal Integration

codeship

g2techgroup

參考資料：

 Ask HN: What’s the largest amount of bad code you have ever seen work?

“ 25,000,000 行的代碼就問你敢不敢動？！” - CSDN的文章 - 知乎

“ 為什麼感覺這工作聽起來很清閒的樣子。。。 ”