[[271471]]

近日，某網(wǎng)友在 Hacker News 上發(fā)起了一個 “你見過的最糟糕的代碼是什么?” 的問題，引起了廣大網(wǎng)友的關注和討論，評論數(shù)已接近600條。其中，一位 ID 為“oraguy”的程序員對 Oracle 數(shù)據(jù)庫代碼的吐槽，更是引發(fā)熱議。內(nèi)容大意如下：

1. Oracle 數(shù)據(jù)庫 12.2。它有近 2500 萬行 C 代碼。

這實在太恐怖了，簡直難以想象!你做不到在不破壞成千上萬個現(xiàn)有測試的情況下更改產(chǎn)品中的單單一行代碼。好幾代程序員在很緊的項目期限內(nèi)編寫了這些代碼，代碼中充斥著各種各樣的垃圾內(nèi)容。

非常復雜的邏輯、內(nèi)存管理、上下文切換等，這些都用數(shù)千個 flag 連接起來。整個代碼充斥著神秘的宏命令，如果不拿出筆記本，并且手動去展開相關的宏命令，就無法理清楚這些命令。甚至可能需要一兩天才能真正理解某個宏命令的作用。

毫不夸張的說，有時你需要理順 20 個不同 flag 的值和效果，來預測代碼在不同情況下的行為方式。有時多達數(shù)百個 flag !

這個產(chǎn)品仍然存活并且仍然可用的唯一原因是數(shù)百萬次的測試!

以下是 Oracle 數(shù)據(jù)庫開發(fā)人員的日常：

• 開始處理一個新的 bug 。
• 花兩周的時間試圖理解 20 個不同的 flag ，這些 flag 以神秘的方式相互交互。
• 再添加一個 flag 來處理新的特殊場景。添加幾行代碼來檢查此 flag ，并解決有問題的情況，規(guī)避該 bug 。
• 將更改提交到包含大約100-200臺服務器的測試服務器集群，這些服務器將編譯代碼，構(gòu)建新的 Oracle 數(shù)據(jù)庫，并以分布式方式運行數(shù)百萬個測試。
• 回家。第二天來上班，繼續(xù)處理別的 bug 。測試可能需要20-30個小時才能完成。
• 再回家。再來上班，檢查你的集群測試結(jié)果。順利的話，會有大約100個失敗的測試。倒霉的話，將有大約1000個失敗的測試。隨機選擇一些測試并試圖搞清楚你的假設出了什么問題?；蛟S還需要考慮10多個 flag 才能真正理解 bug 的本質(zhì)。
• 再添加一些 flag 以嘗試解決問題。再次提交更改以進行測試。再等20-30個小時。
• 來來回回重復兩周，直到你得到了將這些 flag 組合起來的“神秘咒語”。
• 終于有一天，你會成功，不再出現(xiàn)測試失敗。
• 為你的新更改添加100多個測試，以確保下一個不幸接觸這段新代碼的開發(fā)人員永遠不會破壞你的修復。
• 提交最后一輪測試的成果。然后提交以供審核。審查本身可能還需要2周到2個月。所以接下來繼續(xù)去處理下一個 bug 。
• 在2周到2個月之后，一切已就緒，代碼將最終合并到主分支中。

以上就是對在 Oracle 修復 bug 的程序員日常生活的描述，一點也不夸張。現(xiàn)在想象一下開發(fā)新功能會有多么恐怖。開發(fā)一個小功能需要6個月到1年的時間(如果是添加一種新的身份驗證模式，比如支持 AD 身份驗證，可能需要2年)。

這款產(chǎn)品本身就是一個奇跡!

我不再為 Oracle 工作了。永遠不會再為 Oracle 工作了!