重构-在实践中理解

　　在老大的推荐下买了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还是返回空列表？<br>     // 绝大多数情况都是返回空列表好，这个返回什么，可以测试一下，本来一句话搞定的事，饶了这么多弯，简单事情复杂化<br>    ...
    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条件不一样）,但是，完全可以使用列表判断，然后一条执行语句搞定<br>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{  // 注意发生异常后要进行处理
}