持續重構

我是這樣叫他。

直到今天看了「The Clean Coder」（還只用了幾小時當故事書就看完了 XD），才知道原來這個方法被叫做 Merciless Refactoring 。

網路上其實有一些對於無情重構的許多說明，不過在這邊還是想分享我自己的經驗和思維。

引子

我其實在日常的開發過程中，一直在做持續重構。

和 Growth 歸納出來的做法一樣：巨大的成功，需要由許多小的成功累積而成。

核心的想法和敏捷開發相似：敏捷開發鼓勵縮短發布時程，透過每一次的週期（或稱迭代/iteration/sprint）改善產品（這邊「產品」就是指程式碼）。而我自己則是習慣把完成每個小重構或 task 完成當成和發布類似的概念。

另外也跟「童子軍精神」一樣：離開營地時，要比到達時還要乾淨。重構就可以幫忙做到這件事。

再來就是還「技術債」：你我應該都有碰過累積太久的技術債，需要花費大量的時間，或是跟 PM 要一段時間來重構吧！那我就可以透過不斷地持續重構，避免慢慢累積技術債，避免要花非常多的時間成本來還債。

實務上

之前曾經和主管聊到持續重構這件事情。

當時應該正在做的事情還沒有辦法清楚表達，所以在表明要把持續重構加入開發流程的時候，是有被提醒說不要耽誤到承諾的時程。

後來想一想，其實好像就跟撰寫測試差不多的概念，建議可以把重構加入每個 task 的 Definition of Done （完成的定義）中，在每次 commit 時，把自己的 code 變得更加美好。

當堅持一陣子之後，就會更加自然且順暢的完成持續重構，而不會是「又多一份 DoD 的事項了！」的感覺。

一開始一定會卡住 ...

其實重構基本上就是希望自己程式碼的架構能夠改善、降低耦合 bla bla bla 等等。

背後代表的意思大概就是需要有足夠的技術知識，例如 software architecture, design pattern 等等軟體開發（或是工程）上的知識需要補充。

但是當正式專案要去實作自己不熟的 pattern 是很耗時又很危險的，所以就必須在日常生活中不斷練習自己所需要學習的知識到內化，就可以在重構的時候加快處理的速度。

以我自己為例，剛進入業界的時候，很感謝老闆給我時間可以自己琢磨程式上的實作。雖然很感謝，但是在正式專案練功是一件不好的事情。後來就利用下班時間，多看資料或是嘗試不同的架構方式。當熟悉到一定程度之後，再來規劃要如何和合作的同事說明自己的想法以及導入現有或新專案。

其實，擁抱改變對我來說，某種程度上應該是堅持持續重構的結果，而不是一開始的目標。

當累積過逐次重構的改進成果之後，專案本身就會越往漂亮的架構或寫法邁進。要是有做好如「單一職責原則」等的情形下，需要擴充、改變的時候，往往需要的成本真的會低很多很多很多。

我在專案中雖然會多花一點點點點時間堅持做到重構，在當專案需要變更需求時，好幾次都不用花太多的功，就可以完成變更。