給2500萬行代碼修復bug的程序員都怎麼上班?_風聞
差评-差评官方账号-2018-12-25 08:36
文/世超
通常説,一個人造的、很龐大的事物,會給人很厲害的感覺。
比如説摩天大樓⬇️
或者巨型水壩⬇️
看着這種東西,世超不禁想到這幾個字: “ 人類工程學奇蹟 ” 。
但是欣賞歸欣賞,這種巨型工程項目如果出了啥子問題,不得不維護的話,那這個**維護痛苦程度只能用****“ 災難 ”**來形容了。
世超最近在網上就看到了這樣一個科技界的龐然大物: 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的文章 - 知乎
“ 為什麼感覺這工作聽起來很清閒的樣子。。。 ”