什麼樣的程式碼需要被重構？

還記得當我在找第一份後端工作時，曾經有被面試官問到有沒有過重構的經驗？當時的我菜得一批，連重構是什麼都講不出來，最後只吞吞吐吐地說自己沒有重構的經驗。後來，受到教訓的我讓自己慢慢去了解重構之後，才慢慢發現「重構」並不是什麼高大上的名詞，有時甚至你還沒聽過這個名詞時，就已經在重構之中了。
重構──意指在不影響程式碼功能的情況下，進行程式碼的效能、可讀性、可維護性等等進行調整的行為。小到修正命名不良的變數名稱，大到套用設計模式，調整系統的架構 ( 但前提是功能不受影響 )，這些都可以算是重構。
重構──那些變數、方法等級的重構，其實都不算太難。通常會讓人困惑的點更多是在於，我不確定這段程式碼需不需要被重構。假設有一段關於交易的程式碼，中間有超過100行的驗證程式碼，你可能直覺性地覺得應該要提取出來作為一個獨立的方法。但團隊的其他人也許早就習慣了這樣寫，這樣一來，是否真的能夠幫助到其他人理解這段程式碼？
這說明了其實很多標準最終你依然得Align自己的開發團隊，而非盲目遵從某些標準或規範。當然能夠判斷出哪部分的程式碼暴露了不必要的細節這點，也需要一些經驗。
對於這種模糊不清的感覺，有些人可以無師自通，抓出合理的平衡點。如果不是，我會推薦看Kent Beck的《測試驅動開發》，裡面詳細地描述了如何從一個肥胖的程式碼不斷調整，透過大量的測試，一步步將物件的依賴分離與凝聚力的提升。雖然TDD的開發流程是否適合開發團隊使用是個好問題。但做為學習重構程式碼的第一站來說，我還是認為說《測試驅動開發》會很適合初出茅廬的工程師。
此外，對於重構程式碼這件事，TDD還提到一個我認為最重要的觀念。「首先必須要有完善、覆蓋率高的測試程式碼，不然就只是在重寫而已」