重構 (refactoring)主要兩個原則需要遵守：
1. 在不改變程式碼外在行為的前提下，對程式碼做出修正，以改善程式碼內部的結構。
2. 要針對該支程式碼 (一般以類為單位)撰寫白箱的單元測試程式碼 (unit test code)
。
違背上述兩個原則，那就不是稱為重構，而是重寫了。 :-)
何時重構？ Martin Folwer 用了非常饒富意蘊的比喻：「嗅出程式碼的壞味道」。
這裡給您參考基本的兩種壞味道，只要有違背，那就是提醒要重構程式碼了。
1. 單一 method 陳述超過 30行 (atomic 原則，一個 method 只負責單一工作)。
2. method 參數不得超過5個。參數眾多肯定是沒有作好參數的資料傳遞物件 (DTO,
data transfer object)結構的組織。
重構的目的為何？當然是為了增進程式碼的品質。重構的好處是什麼？當然是讓程式碼更
具彈性可維護與延展性。重構是為了誰？當然要先為了自己，程式碼簡潔易讀好維護，工
作才可能輕鬆有意義，而後才有可能擴展到團隊乃至全公司，形成一種善文化。獨善其身
，才有可能兼善天下。
※ 引述《srwhite (阿白)》之銘言：
: 事情是這樣的
: 小弟最近接到使用者需求
: 要增加幾個跟之前很像的功能
: 舊的那隻程式已經歷經許多測試 目前正穩定的運作中
: 但最初的需求很單純
: 因此設計得不是很有彈性 不利於擴充及更改
: 第一次接到需求的時候
: 我想了一下覺得重構有點麻煩
: 於是直接複製了一份然後改了需要改的地方
: 變成兩隻有八成像的程式 各做各的
: 但最近又要再增加一個
: 於是我開始猶豫該不該整個打掉重構
: 避免程式碼繼續這樣擴張下去 感覺很不專業
: 之後再有需求也比較好調整
: 但如果複製改一改大概只要一個小時
: 打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug
: 想請教大家在類似的情況
: 都用哪些標準來決定甚麼時候應該重構