学习了！对我影响最深刻的一次代码重构

1. 业务说明

系统原先已有登录功能，我们打算增加一个登录IP和允许登录时间的安全限制业务。

IP 分为内网ip、外网ip，如果设置了，则该用户只允许在这些ip登录

2. 原有代码贴图

登录代码原先已有，这是增加的功能，该同事增加的代码如下：

图1：login方法中，判断是否可以登录的私有方法调用

图2、3、4该私有业务实现方法。

3 原有代码问题分析

从该方法的调用方式，到该方法的实现，代码都存在不少问题，我先逐一分析，然后再贴上我重构的代码以及重构的思路。

1. 调用方式

   用String匹配的方式判断，直接用boolean判断即可。

2. 时间hh:MM的处理 应该写成工具类，避免重复。

3. 字符串分割的处理 多个地方存在将字符串（逗号分隔）分割为集合的代码，应该写成工具类，可读性好，并避免重复。

4. 三种比较业务缠绕到一起，业务可读性差。这里涉及允许时间判断、内网ip、外网ip三个业务判断，但是代码通过循环缠绕到一起，可读性差，不够聚合，难以修改。

5. 多处存在SecureLogEvent的构造（构造安全日志记录），并且没有将关键业务数据传入。

6. 注释很少，关键代码不容易阅读。

7. 方法命名不够准确、明确。

8. Magic Code太多，应该重构为常量。

4 重构过程说明

由于重构过程的代码是反复修改，所以已经不好拿回，我先说明一下我的重构过程，然后将重构结果代码贴上，这样读者应该可以基本理解了。

1. 先阅读该部分代码，观察那里存在重复。
2. 将将时间处理分割出来，作为独立私有子方法。
3. 写好后，写个main函数测试一下，没问题了就替换原方法中时间处理部分的代码。
4. 阅读字符串分割相关代码，找出其共性，然后写私有方法、测试、替换。
5. 观察原先代码，【允许登录时间】判断是在两重循环里面进行判断，但是从业务角度，只要不在允许范围，哪怕ip允许也是一样不行的，所以应该单独判断，而不是放在循环里面。
6. 内网ip判断、外网ip判断，同理，也应该可以独立判断，所以两重循环就可以拆成两个独立的循环了。
7. 业务理清后，代码层次就清晰了。
8. 然后将日志增加有价值的业务数据、代码加上注释、魔术字重构为常量等。
9. 将调用处（前面图1）改为boolean方式。
10. 将整个规则判断代码从CreditController中移出去，新建一个合适的工具类存放，一来减少该Controller代码，二来以后类似的扩展都已放到该工具类中，职责更加分明。

5 重构后的代码

图1：调用处，改为工具类，并且返回boolean，命名方面可读性明确，禁止ip和访问时间，如果返回true，就跳回登录页面。

图2、3：

• 最上面是常量。
• 然后下面是目前本类唯一一个公有方法。
• 先判断允许方法时间，调用私有方法forbitVisitTimeRange。
• 然后下面isInside（是否可以内网访问）、isOutside（是否可以外网访问）分别判断（调用checkRange私有方法），去掉了两重循环。
• recordLog写成私有方法，并允许传入拼接信息，把有业务意义的关键数据也写到日志中。

图4、5、6三个图。

• 时间处理：通过ToDay工具类（我的框架自带）处理，可读性更好。
• 逗号分隔的字符串的分割方法，用框架的工具类，并通过两层的私有方法，让代码更容易维护。
• 写日志的私有方法，增加了拼接业务数据字符串的参数供传入。

6. 总结

• 避免重复代码 看到重复代码，务必想办法把它抽离出来重用。
• 善用工具类 无论自己框架的还是第三方开源框架的，不要自己发明轮子，如果没有，甚至自己写一个工具方法，这样可以让代码更关注业务。
• 涉及多重循环时，好好考虑一下是不是一定要这样做才可以。能否每个业务一个独立的子方法？
• 注释不能省，而且对于关键代码，有注释可读性大大提升。
• 魔术字要重构为常量。
• 写日志时，切记不要写那种没有参考价值的日志。你要考虑一下，如果以后业务出错或者出现意外需要回看日志时，这些信息够不够，能不能让你足够的重现当时的场景