个人决定的标准是看 "有没有时间",
有的话就是随时都可以重构
不过我觉得重构并不是要花很多时间去做大幅度修改,
而是花少少时间可以做的小修改,
而每次小修改都可以好一些, 累积起来就是很大的改进
举某个个人最近做过的例子
某根据数据库状态及接收到的资料做各种检查的程式,
本来是取资料、各种检查都写在一个 大~~~方法里面,
有一堆 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
: 想请教大家在类似的情况
: 都用哪些标准来决定什么时候应该重构