一夜之間格式化兩千五百萬行程式碼：rubyfmt 的故事

背景

這篇文章記錄了支付巨頭 Stripe 如何在一個週末內，將其規模達 2,500 萬行的 Ruby 程式碼庫進行全自動格式化重整。這項工程不僅涉及開發內部的 rubyfmt 工具，更挑戰了在極大規模的單一程式碼庫（Monorepo）中，如何在不干擾數千名工程師開發流程的情況下，完成史上最大規模的程式碼變更。

社群觀點

在 Hacker News 的討論中，首要的爭議點圍繞在 Stripe 選擇 Ruby 作為核心金融系統語言的合理性。部分評論者對一家處理全球金流的公司依賴 Ruby 感到不安，認為這種動態語言在安全性與效能上可能存在隱憂。然而，多數資深開發者反駁了這種「語言歧視」，指出 Stripe 的成功證明了技術選擇並非決定公司成敗的唯一因素，且 Ruby 的開發效率讓公司能快速迭代。更有讀者指出，Stripe 實際上使用的是經過 Sorbet 強化後的 Ruby，具備靜態型別檢查功能，這與傳統認知的 Ruby 已大不相同。

關於程式碼規模的討論也引發了熱議。許多人對 2,500 萬行（甚至有留言指出目前已達 4,200 萬行）的數字感到震驚，懷疑如此龐大的程式碼庫是否會導致維護災難。對此，有觀點認為這反映了大型企業在長期發展下的必然結果，並以 Google 擁有數十億行程式碼為例，說明規模化管理是所有科技巨頭必須面對的課題。討論中也觸及了 AI 時代下程式碼格式化的必要性，有人質疑既然未來程式碼可能多由 AI 生成與閱讀，人類是否還需要執著於縮排與佈局；但反對者認為，只要人類仍需參與除錯與審核，可讀性就是不可妥協的底線。

在執行策略上，Stripe 選擇「一次性全量更新」的做法引發了技術細節的探討。有經驗的開發者分享了不同的策略，例如透過腳本分批處理未被 PR 佔用的檔案，以減少合併衝突。然而，Stripe 選擇在週六進行，並利用強大的測試套件來確保正確性。來自 Dart 團隊的成員分享了一個關鍵的保險機制：在格式化工具中加入「非空白字元校驗」，確保格式化前後除了空白字元外，所有實質代碼完全一致。這種做法能極大程度消除大規模變更時的恐懼感，確保格式化工具不會意外改變程式邏輯。

最後，留言區也出現了一些有趣的軼事，例如有開發者回憶早期職涯中，為了應對不愛格式化的主管，特地撰寫了能將程式碼在「整潔」與「混亂」間切換的工具。這些討論共同指向一個共識：在現代軟體工程中，自動化格式化工具已不再是可有可無的選項，而是維持團隊協作效率與程式碼品質的基礎建設。

延伸閱讀

• Sorbet：Stripe 開源的 Ruby 靜態型別檢查器。
• Google 儲存數十億行程式碼的經驗分享：探討超大規模程式碼庫的管理挑戰。
• Ruby Typing 發展現況：關於 Ruby 社群在型別系統上的演進觀察。