Hacker News
This article discusses the concept of 'ratchets' in software development, analogous to mechanical ratchets, where progress is made in one direction but cannot be easily reversed, often leading to technical debt or undesirable states.
AI 生成摘要
本文探討了軟體開發中的「棘輪」概念，類似於機械棘輪，進步只能朝一個方向進行，難以逆轉，常導致技術債務或不良狀態。
在軟體開發中，當面對龐大的遺留代碼（Legacy Code）時，直接引入嚴格的 Linter 規則或修復所有過時模式往往不切實際。qntm.org 的文章提出了一種名為「棘輪」（Ratchet）的機制：不要求立即清空所有錯誤，而是記錄當前的錯誤總數，並強制規定未來的錯誤數只能減少、不能增加。這種做法就像機械上的棘輪，讓代碼質量只能單向朝著更好的方向演進。
Hacker News 的討論顯示，這種「棘輪」概念在業界早已以不同名稱存在，最常見的說法是「基準線」（Baselines）或「祖父條款」（Grandfathering）。許多開發者分享了在大型企業實踐此類系統的經驗，認為這比單純將 linter 設為警告（Warning）有效得多。當警告過多時，開發者往往會產生視覺疲勞進而忽視，而棘輪機制則能將「不增加新債」變成一種硬性的 CI 門檻。例如，Notion 的工程團隊便廣泛使用這種模式，將違反規則的清單存儲在版本控制中，確保任何新提交的代碼都必須符合更嚴格的標準。
然而，單純「計數」的棘輪機制也引發了技術細節上的爭論。部分評論者指出，如果只追蹤錯誤總數，可能會出現「抵銷效應」：開發者在 A 處修復了一個舊錯誤，卻在 B 處引入了一個新錯誤，導致總數不變，這違背了棘輪的初衷。為了應對這一點，更成熟的方案是採用「文件級別」或「行級別」的白名單。RuboCop 或 golangci-lint 等工具已經內建了類似 TODO 文件或問題追蹤的功能，能精確鎖定哪些舊代碼被豁免，從而防止新代碼鑽漏洞。
另一個有趣的討論點在於開發者體驗。有意見認為，當開發者修復了舊錯誤後，棘輪機制若強制要求手動更新「預期錯誤數」配置文件，反而會變成一種對「做好事」的懲罰。對此，有人建議應由 CI 自動更新基準線，或利用版本控制的上下文來區分新舊代碼。此外，隨著 AI 代理（Agents）參與開發，棘輪機制展現了新的價值：它可以作為 AI 的行為邊界，禁止 AI 引入特定的不良模式，甚至能驅動背景運行的清理代理，在不干擾人類開發者的情況下逐步消除遺留問題。
儘管如此，仍有開發者偏好更顯式的做法，例如在代碼中使用抑制註解（Suppression Annotations）。他們認為將錯誤標記在代碼旁邊比維護一個集中的計數文件更具可讀性，且能透過 Git 歷史輕鬆追蹤進度。總體而言，社群達成了一種共識：無論具體實現方式為何，這種「不求一步到位，但求持續改進」的務實主義，是處理大規模技術債務最有效的方法之一。