Oracle 12.2。它有近2500萬行C代碼。

這有多恐怖，簡直難以想像！你無法在不破壞成千上萬個現有測試的情況下更改產品中的單行代碼。好幾代程序員在有限的項目期限內編寫了這些代碼，其中充斥著大量的垃圾代碼。

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

有時你需要理順20 個不同flag 的值和效果來預測代碼在不同情況下的行為方式。有時多達數百個flag ！這一點也不誇張。

這個產品仍然存活並且仍然可用的唯一原因是數百萬次的測試！

以下是Oracle數據庫人員的日常：

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

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

這款產品本身就是一個奇蹟！

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

原文地址