我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。
重構的目的
我們之所以會認為重構是一種「任務」是因為想要去消除技術債，然而重構是為了讓下一個功能能夠被持續的加入到產品中所做的修改。
那麼，要如何為「下一次修改」而準備進行重構呢？實際上就是我們在討論的壞味道問題。舉例來說，用最容易注意到的「重複」問題來看，假設我們已經發現了產品中有重複的程式碼可以改寫，如果不進行重構重複使用的話，在下一次的時候可能就會變成複製貼上的實作，並且慢慢的累積出更多重複的部分，最後變成技術債。當我們有測試、持續整合的協助下，我們可以安心的修改實作在開發中不斷的重構消除掉這些壞味道，那麼我們的程式碼品質就會持續的維持在一個相對高的水準。
重新思考重構
其實，卡住我們重構的一大問題是要做大規模的改寫，同時對測試沒有信心。然而我們從驗收驅動測試的角度開始思考，會注意到我們可以從「使用者直接注意到」的地方開始。
這其實也就是重構的定義中「不改變外部行為的前提下，對內部結構的改善」的處理，當我們從最外層開始思考一層一層的修改，也許重構也沒有想像中那麼的可怕。
因為我們不再需要將完整的功能全部修改，而是以一個功能為單位，一層一層的由上而下（Top-down）的改寫，直到最後就能夠將整個產品中的技術債消除，同時因為我們只關注「功能」的實現，如果沒有要修改的必要也可以先不調整，這樣也明確的限定了重構的範圍，相比過去一但開始就會有一大堆實作要一起調整的狀況，也明確許多。
封面圖片使用 Unsplash 上 Eugen Str 的作品，這系列的文章只是課程的一小部分，因此並無法完整涵蓋所有概念以及精神，看關於技術的主題可以到弦而時習之找找靈感。
