个人在重构代码中的心得体会

Posted 2020-10-09 风云无敌

最近在维护客户的电子商务系统过程中对该系统的代码进行了一些简单的重构。我本来不是一个爱重构的人习惯于随意的书写代码心底里认为没有必要搞那么多花哨的东西毕竟现在的开发模式大多数是MVC已经提供了固定的代码分层和代码层级，但这次简直是忍不了了代码太庞大（1000行代码在一个方法体里面，还只是其中的一个方法）,因此动手收拾一下代码。我具体做法如下：

1 对代码进行分组，分组原则是每一个小处理，每个分支代码块为单位，把相近的的代码移动到最近的位置.这样做的好处在于能够提供流畅的阅读，不用去满篇的去找某个变量或者方法，保证了阅读的连贯性，毕竟代码太长读完后面 ，前面走就还给作者了

2 新建方法把大的分组移入到新方法中。我暂且称它为拆分方法，再将大的分组移到新方法时往往会有大量广联的变量需要一起移入，虽然我们在这之前进行了一些变量移动但是还有好多全局变量。对于不能移入到新方法的，我以参数的形式传入，由于输出只有一个而新方法也有好多与原方法关联的输出，我采用out 参数传出（这个只针对了输出变量为值类型的，如果参数是引用类型就不用多此一举了）。这样做主要是为了减小方法体让文件可阅读性更高。

3 将新方法引入到原方法，并做单元测试

4 重复步骤2，3 直到原方法体变到合适的大小,至于多少代码的方法体式合适的方法体，我这里没有具体的答案，推荐在50到100行，但根据实际情况来的

5 修改方法名字，让他更贴近方法方法实际处理的业务，见文生义是我喜闻乐见的命名方式，这样其他人见到名字就能明白方法是干嘛不用再去研读方法的逻辑了，增加了又好性

6修改方法的参数。刚刚分离出来的方法，由于保留与原方法体里面的原始逻辑，所以有可能传入参数比较多，因此在有必要的时候新生成View Model类作为新的输入输出参数，将多余的参数变为新参数的属性。同时修改原方法以适应对应的变化。

7对修改进行单元测试，其实我们每做一次修改最好做一次单元测试以保证没有异常出现和功能的正常运行

8移动与当前类无关的代码到他对应的类中，这样更能满足面向对象的高内聚低耦合的原则

9 将几个类公用的逻辑放到新类或者其父类中，这样可以减少冗余逻辑和代码，减少以后在修改时遗漏导致错误

10使用了相关的设计模式，减少代码的关联比如工厂模式批量生成类实例

终于把自己这几天做了的和计划要做的步骤写出来了，经过初步的整理代码干净了不少 ，有时候就像打扫自己房间一样，做做代码的整理，既方便自己也方便后人