重构

为什么要重构

在业务场景简单的情况下。简单的实现是比较好的选择。这个时候呢，我们的业务代码会比较简单短小，且满足了业务需求。但是，当你的业务开始变得复杂，你的业务渠道变多的时候。如果不进行重构，还是一味的以怎么简单怎么来的思路。像这样搭积木一样，不停的往上盖，总有一天你的积木会由于根基会撑不住高度而倒塌。虽然说这种方式写代码不会让你的代码不能运行。但是你的代码里面就会有很多重复的代码，一堆if-else或者switch-case，一堆的try-catch代码块，整体代码的可读性就非常的差，以后维护起来相当的麻烦。
《Clean Code》中提到，当我们在开发中，多数时间都在滚动屏幕，浏览其它模块。读与写花费的时候比超过10:1。在写新代码的时候，我们一直在读旧代码。所以重构势在必行！

重构之前

老话讲，兵马未动粮草先行。同样我们在重构之前也要先行准备一番。

让它能工作

在你重构之前自己一定要对原有的代码进行功能测试。自己本地运行一次，然后调用下需要重构的模块API。保证代码可以运行。

单元测试

不管你将要重构的代码是你熟悉的还是不熟悉的，在重构之前要写好单元测试，保证你要重构的模块覆盖率100%。单元测试不仅可以让你验证你的模块是正确的，而且给你重构代码加了一层保障（重构代码不是更改模块功能，故重构完可以用单元测试进行验证）。

重构Tips

• 避免重复（DRY）
• 设计模式的六大原则
• 不合理的命名、注释
• 函数参数尽可能的少，类、方法应该短小
• 不要注释代码和不要出现永远执行不到的代码
• 垂直分隔：局部变量，私有方法要靠近被使用的地方
• 尽量避免循环调用链（a.getA().getB().getC()）
• 用多态替代if-else或switch-case
• 封装条件：对于那种很长的if条件要把条件封装成方法或者变量，易于理解
• 类或者方法应该根据实际场景，放到它该有的位置，不要随意
• 童子军军规：让营地比你来时更干净
• 遵循自己团队的开发规范

小结

当重构代码的时候，应该一小块一小块的去重构。重构是逐步完成的，每一次小的重构都要执行下单元测试，保证重构的正确性。重构是无止境的，但是也要量力而行，不要钻牛角尖。