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

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.122.227 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1542253705.A.860.html