程序員最害怕的是什么？無疑是“屎山”，即前輩們留下來的“祖?zhèn)鞔a”。

在某論壇上，有網(wǎng)友發(fā)起了一個(gè) “你見過的最糟糕的代碼是什么”？有一位 ID 為“oraguy”的程序員對(duì) Oracle 數(shù)據(jù)庫代碼瘋狂吐槽，在當(dāng)時(shí)引發(fā)熱議。

全文如下：

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

這有多恐怖，簡直難以想象！

你無法在不破壞成千上萬個(gè)現(xiàn)有測試的情況下更改產(chǎn)品中的單行代碼。好幾代程序員在有限的項(xiàng)目期限內(nèi)編寫了這些代碼，其中充斥著大量的垃圾代碼。

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

有時(shí)你需要理順20個(gè)不同 flag 的值和效果來預(yù)測代碼在不同情況下的行為方式，有時(shí)多達(dá)數(shù)百個(gè) flag ！這一點(diǎn)也不夸張。

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

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

開始處理一個(gè)新的 bug 。

花兩周的時(shí)間試圖理解20個(gè)不同的 flag ，這些 flag 以神秘的方式相互交互，導(dǎo)致這個(gè)困境。

再添加一個(gè) flag 來處理新的特殊場景。添加幾行代碼來檢查此 flag ，并解決有問題的情況，規(guī)避該 bug 。將更改提交到包含大約100-200臺(tái)服務(wù)器的測試服務(wù)器集群，這些服務(wù)器將編譯代碼，構(gòu)建新的 Oracle 數(shù)據(jù)庫，并以分布式方式運(yùn)行數(shù)百萬個(gè)測試。

回家。第二天來上班，繼續(xù)處理別的 bug，測試可能需要20-30個(gè)小時(shí)才能完成。

再回家，再來上班，檢查你的集群測試結(jié)果。順利的話，會(huì)有大約100個(gè)失敗的測試；倒霉的話，將有大約1000個(gè)失敗的測試。隨機(jī)選擇一些測試并試圖搞清楚你的假設(shè)出了什么問題，或許還需要考慮10多個(gè) flag 才能真正理解 bug 的本質(zhì)。

再添加一些 flag 以嘗試解決問題，再次提交更改以進(jìn)行測試，再等20-30個(gè)小時(shí)。

來來回回重復(fù)兩周，直到你得到了將這些 flag 組合起來的“神秘咒語”。

終有一天，你會(huì)成功，不再出現(xiàn)測試失敗。

為你的新更改添加100多個(gè)測試，以確保下一個(gè)不幸接觸這段新代碼的開發(fā)人員永遠(yuǎn)不會(huì)破壞你的修復(fù)。提交最后一輪測試的成果，然后提交以供審核。審查本身可能還需要2周到2個(gè)月，所以現(xiàn)在繼續(xù)去處理下一個(gè) bug 。

在2周到2個(gè)月之后，一切已就緒，代碼將最終合并到主分支中。

以上就是對(duì)在 Oracle 修復(fù) bug 的程序員日常生活的描述，一點(diǎn)也不夸張?，F(xiàn)在想象一下開發(fā)新功能會(huì)有多么恐怖。

開發(fā)一個(gè)小功能需要6個(gè)月到1年的時(shí)間。 (如果是添加一種新的身份驗(yàn)證模式，比如支持 AD 身份驗(yàn)證，可能需要2年)。

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

我不再為 Oracle 工作了，永遠(yuǎn)不會(huì)再為 Oracle 工作了!