在老大的推荐下买了Martin Fowler的<Refactoring improving the design of existing code>,其实这本书就是作者重构的经验之谈,随便翻一下,尽管你看的多么仔细,如果你没有在实践中感受到它或者应用到它,其实你很难在需要的时候用上。
昨天服务上线的时候,老大就给我上了一课,首先是一个同事定位到我的一个查询接口超时,于是老大就和我一起看着块超时的代码,看到了这样的代码:
B(){ // 在B中发现了代码块BlockA是冗余代码,其实是可以使用一定的方法删掉的,但是我为了省事,就没有优化,并且也没有想到怎么去掉这个冗余
... // 但是这个BlockA就是查询数据库的代码,是非常耗时的,考虑到性能,就该拿掉,如果是非耗时操作,也就算了,但是这个耗时影响了性能问题。
BlockA // 其实我一开始想不到怎么重构,因为在我的潜意思里还是认为B应该call A,有这个前提,可以证明,是无法拿掉冗余代码BlockA的。
... // 看重构的第六章,第一节就是讲把一些块抽出来,创建函数,这个BlockA已经重复调用了,所以更应该抽出一个函数来。
A(); // 我潜意思里想B必要要调用A,是因为我先写好了A,已经把A当成了最基本的单元操作,其实不是的,还有更细的单元操作,后写B,没有将A,B放在一起看。
... // haha,感觉化学工程中学习的化工反应原理中的单元操作这个概念,用在编程上,一样很6啊,这是后话
}
A(){
...
BlockA;
...
}
老大优化的代码:
B(){ // 因为在B中减少了BlockC的冗余操作,时间性能提升了约1/3,从接口看,时间性能提升还是很明显的。
... // 但是,不是说这样做就没有代价,当然从理解上看,函数数量少的代码通常比函数数量多的代码好理解,并且理解了A,就可以很容易理解B。
C(); // 我应该属于大粒度编程,在已经有A的情况下,编写B就很简单,简单也是一种优势。
...
}
A(){
...
C();
...
}
C(){
...
}
然后再说一下代码中的坏味道,也就是<Refactoring>第三章中讲到的一些内容,一种是和语言相关的,一种是和语言无关的。 把我之前的我的一次代码检视和本次重构进行一次总结,先说和语言相关的,java
A(){ // 这个代码让人看了不知道代码在干啥,有点画蛇添足的味道,是不信任ProjectDao吗,ProjectDao会返回null还是返回空列表?
// 绝大多数情况都是返回空列表好,这个返回什么,可以测试一下,本来一句话搞定的事,饶了这么多弯,简单事情复杂化
...
List<String> users = ProjectDao.getUsers(String groupId);
List<String> usersCopy = new ArrayList<String>();
if (users == null && !users.isEmpty){
usersCopy.addAll(users);
}
usersAssign.add(usersCopy);
...
}
B(){ // 这个就是重复代码,虽然不是完全重复(d条件不一样),但是,完全可以使用列表判断,然后一条执行语句搞定
if (a){
BlockA
}if (b){
BlockA
}if (c){
BlockB
}if (d){
BlockB
}
...
}
class c{ // 这个是英文SimpleDageFormat是线程不安全的,在web这种天然并发的应用中使用,非常不合适。较为优雅方法有二:1在方法中使用局部变量SimpleFormatDate,
priate static final SimpleDateFormat sdf = new SimpleDateFormat(); //2.使用DateTimeFormmter和LocalDateTime并发安全类,就是有些不习惯
}
if (A && B && !C){
}esle{} // 这个else就是对if中的条件求反,可以看到,那么多情况并不是你想要的,对于A,B默认为真,可以去掉
class Controller{ // 注意发生异常后要进行处理
}
和语言无关的就是变量命名,注释没有更新等。所以软件工程,实践很重要,要做到理论和实践相结合,事半功倍。