前言

寫程式久了，總會看到一些讓人手癢的程式碼。

變數命名怪怪的、方法太長、邏輯繞來繞去，第一個反應可能是：「我想把它重寫掉。」

但重構不是單純把程式改成自己喜歡的樣子。

重構的目標應該是降低維護成本，而且不能改變原本行為。

重構前先確認目的

我覺得重構前要先問：

  • 這段程式現在造成什麼問題？
  • 是讀不懂、難測試、容易出錯，還是擴充困難？
  • 這次重構能解決哪個具體痛點？
  • 有沒有測試可以保護行為不變？

如果答案只是「我覺得不漂亮」，那可能還不到需要重構的程度。

程式碼當然可以追求美感，但在工作專案裡，改動要有足夠理由。

小步調整比大爆改安全

重構最怕一次改太多。

例如同時做：

  • 改命名
  • 拆方法
  • 換設計模式
  • 改資料結構
  • 順便修 bug

這樣 review 很難看，出問題也很難定位。

比較安全的方式是小步調整：

1
2
3
4
先補測試
再拆出方法
再改善命名
最後才調整結構

每一步都保持可執行、可驗證。

不要把修 bug 和重構混在一起

修 bug 是改變錯誤行為。

重構是不改變行為，只改善內部結構。

如果兩件事混在同一個 commit 或 PR，未來追問題會比較麻煩。

比較好的做法是：

1
2
3
commit 1: Add regression test for login timeout
commit 2: Fix login timeout handling
commit 3: Refactor session validation flow

這樣每個變更的目的都很清楚。

有測試會安心很多

重構最重要的保護網就是測試。

如果完全沒有測試，重構時就只能靠人工點畫面或憑印象確認。

但人很容易漏掉邊界情境。

所以在重構前，如果那段邏輯很重要，我會先補幾個測試，至少保護主要行為。

有測試不代表不會出錯，但能讓你比較有信心。

結語

重構是一種整理，不是推倒重來。

我會用這幾個原則提醒自己：

  • 先確認重構目的。
  • 小步調整，不一次大爆改。
  • 修 bug 和重構盡量分開。
  • 重要邏輯先補測試。
  • 重構後外部行為應該保持一致。

好的重構會讓下一次修改更容易，而不是讓大家重新學一次這段程式。