什麼時候需要重構程式碼？

[Jian-Min-Huang]

• 性能議題要重構嗎？
  • 其實不一定喔
• BUG議題要重構嗎？
  • 這個不叫重構，這個叫做被追殺
• 程式碼太醜要重構嗎？
  • 看團隊，但不是自己開心就好，要整個團隊一起考量
• 有時候你需要的不是重構 👀

新手提問

重構的古典定義是，在不敢變外部行為的前提下，改善內部的實作、架構。那麼，如果是某個外部行為突然具有高價值，需要被獨立出來；或是其他的外部行為可以被原地消滅。這個獨立出來，順便改善的過程，需不需要透過重構的方式？還算不算是一種重構的工法？

半個新手的回答

重構並不是開發新功能，不會有產出，因此不論是把 “外部行為” 獨立出來，或是 “消滅” 其他功能，這就是一個開發工作了，不是重構。

如果真的要定義 “重整高價值功能” 是在幹什麼，你要稱為重工、砍掉重練、隕石開發 ... 都可以，也都不重要 ~。重要的是，可以藉著這次 “非古典重構” 的機會，導入更好的開發習慣，建立測試保護等。(ex. TDD，或是單純先把單元測試做好)

[qrtt1]

如果要嚴格一點來看，你打算「重構」的部分，有在「測試」保護的情況下，確保外部行為不變為前提。那你的修改可以稱為重構。如果並沒有測試保護，那只能稱為 重寫 呦！

所以，當你要改的部分，並沒有測試案例去掩護時，可以先加測試案例，順便提高測試覆蓋率。在此之後的改寫，才是重構。