不管你有多急著要成果，除非你重構完這個系統就完全沒自己的事情了...

(點選標題閱讀全文)



任何BUG都不會找你，任何使用程式的問題全部跟你無關，你都不用負責任，那，你可以隨便改

但事實並非如此，你改的任何地方都是將來可能出BUG被問的地方
如果你是接別人的程式來重構，還沒讀懂之前就隨便抓出任何一小段
"這檔案看起來就很重要，讀完大概就沒問題了，其他都不用管，先改這個就對了"
"對了，這地方很複雜懶得看，一定有問題啦，全部砍掉重寫"
"錯誤訊息都看不懂啦，沒關係反正搞懂輸入輸出然後看不懂的全部砍掉，以後再說"

在你能正確使用別人程式做事情之前，尤其是文件不足的時候
猜測怎麼運行然後去驗證他，遠比整理input output有用
相依關係是很重要，可是怎麼使用他一問三不知的情況，請不要以為分析出相依關係就能開始動工了，這無疑是慢性，不，急著自殺

重構是要停下來動腦筋的，冷靜檢視運作方法，確認準備重構的部分都讀懂
"且自己真的知道怎麼使用，中間參數是什麼意義"
(絕非整理程式相依性，簡單估算運作流程，和輸入輸出以後你就自動，突然會用了)
請確實去"使用"程式，"測試"程式，"觀察"程式對於你的輸入是否真的有期望的輸出
你可以不用死板的寫unit test，因為你通常要重構的都不會有unit，重構後也可能也不一定能有漂亮的unit
(如果原本的結果內容已經不夠單純，或重構成unit會導致檔案物件大量產生，那麼硬要做出最小unit是相當危險的，我們是要讓程式更好改，而不是全部minimum unit以後，因為本身複雜邏輯，結果改一個動作就要改幾十個檔案...)[註1]

但是即使擺脫unit test(phpunit ,junit等等也不適合整合性質的測試)
即使完全不寫程式，你本身完全就可以主動期望結果並且去驗證他

重構絕非把自己當成作業員然後認為你"反正就是要把哪些內容固定砍掉，然後固定出什麼輸入輸出之類的，其他不用管，不用思考"
對code的替換作業是全面思考，全面測試，全面規劃以後，最後要收尾甚至交給機器收尾的事情



註1:
有些人會覺得很奇怪，如果有正確的min unit為什麼還會發生這種事情呢?他做的事情不是完全隔離開來，非常方便整合與再利用了嗎?
但現實上，你即使是呼叫API的方式，要處理一件事情通常都會有大量的流程與邏輯(看成SOP就好)，在這情況min unit通常是不會充分滿足邏輯需求的，也是為什麼流程和邏輯"只要稍微改變"，看似完美獨立運作且可重複利用的min unit就挫勒等了

究其原因...?因為min unit不可能預想到以後所有改版並把那些情況都參數化阿....非常直覺的理由，而且一定很多人不想承認這個事實

這裡要先清楚知道一件事情，別人寫的程式架構很漂亮，也確實有發揮那個好處，
但你的系統並不一定可以利用那個所謂漂亮的架構得到同樣的好處，請務必不要直接套下去(尤其是min unit化)然後就當成優化了