選擇重寫而非重構的教訓

前言

當模組邊界本身就是錯的，漸進式重構就不再是穩妥選項。文章回顧一場持續兩季的遷移：哪些東西被保留下來、哪些建議被我們忽略，以及差點出事的兩個環節。

小事的複利

回顧 Technical Discussion 的工作，真正的收穫都不怎麼華麗：一次命名修正、一個被刪掉的設定、一份再也沒改過的檢查清單。

為什麼它們撐得下來

• 它們由一個人負責，而不是一個委員會。
• 它們上線時，附帶了「何時會失效」的觀察方式。
• 它們拿掉了一個決策，而不是多寫了一份文件。

直接偷走

挑一個這個月你已經抱怨三次的痛點。那就是你的下一個專案——它已經證明過自己的續航力。

結語

大重寫的故事比較好聽；小步複利的系統比較好用。