個人決定的標準是看 "有沒有時間",
有的話就是隨時都可以重構
不過我覺得重構並不是要花很多時間去做大幅度修改,
而是花少少時間可以做的小修改,
而每次小修改都可以好一些, 累積起來就是很大的改進
舉某個個人最近做過的例子
某根據資料庫狀態及接收到的資料做各種檢查的程式,
本來是取資料、各種檢查都寫在一個 大~~~方法裡面,
有一堆 if else for 等等的包來包去
依以下步驟慢慢改
1. 整理資料, 將各種資料歸到不同 Class,
如果有需要就加 Class、加方法、抽共用
這一步只是做些整理包裝之類的,
對原本程式還沒做什麼修改, 只是某些地方取值改成由某物件拿
2. 資料整理完, 那就可以做個 DataProvider 之類的,
將取資料的部份切出去
3. 接下來針對各種檢查, 以 Template 模式定義好一個檢查該有的步驟,
然後就可以對 "各種檢查" 定義出 "各別的 Class",
這一步也沒怎麼改原本程式, 只是把原本一大串的程式搬家,
放到各個對應 class 的檢查方法裡,
這樣要針對某項檢查做調整時就很好找
4. 做好一堆檢查的 class,
就可以用 chain of responsibility 模式把它們串起來,
這一步還是沒有怎麼動到原本的程式,
但未來要增加、刪除某些檢查就方便多了
5. 最後才是細看各項檢查的 class 裡的程式,
有沒有重覆做的事情, 看要提出共用方法, 還是加進 Template 的步驟,
或能不能一開始做一次就好
這時才真的比較大幅度的去改動到原本的程式,
但也是能一小部份一小部份改, 有多少時間改多少
其中每一個步驟大概一小時, 頂多半天,
任一步做完都可以暫停, 其它的之後有時間再繼續
不過當然能一口氣做完還是比較好啦
總之, 個人覺得重構應該是
"一連串小修改, 其中每一項都不會花太多時間並能有實際的改善"
如果不是, 那很可能是對整個程式還沒有足夠的理解,
或者對整理程式上需要的相關技巧還不夠熟悉,
那或許先不急著重構, 而是把程式搞清楚、相關整理方式跟步驟整理好,
之後再一步一步的做
修改前修改後的對比大概像這樣
修改前
// ...十幾行 query + 準備資料
for (/* loop 資料 */) {
// 上百行各項檢查、記錄錯誤狀態、送錯誤通知
}
修改後
// 拿資料
List<Data> datas = DataProvider.getDataToCheck();
// 準備好各項檢查
Validator validator = new ValidatorOne()
.setNext(new ValidatorTwo())
.setNext(new ValidatorThree())
.setNext(new ValidatorFour())
.setNext(new ValidatorFive());
List<String> msgs = new ArrayList<String>();
for (Data data : datas) {
validator.validate(data, msgs); // 檢查資料, 有事請記在 msgs
Notification.notify(msgs); // msgs 裡如果有事要通知就會通知
}
※ 引述《srwhite (阿白)》之銘言：
: 事情是這樣的
: 小弟最近接到使用者需求
: 要增加幾個跟之前很像的功能
: 舊的那隻程式已經歷經許多測試 目前正穩定的運作中
: 但最初的需求很單純
: 因此設計得不是很有彈性 不利於擴充及更改
: 第一次接到需求的時候
: 我想了一下覺得重構有點麻煩
: 於是直接複製了一份然後改了需要改的地方
: 變成兩隻有八成像的程式 各做各的
: 但最近又要再增加一個
: 於是我開始猶豫該不該整個打掉重構
: 避免程式碼繼續這樣擴張下去 感覺很不專業
: 之後再有需求也比較好調整
: 但如果複製改一改大概只要一個小時
: 打掉重構可能要一個禮拜 還不保證會不會有甚麼多出來的bug
: 想請教大家在類似的情況
: 都用哪些標準來決定甚麼時候應該重構