本文來源：http://r6d.cn/BV2D
1. 業務說明
系統原先已有登錄功能，我們打算增加一個登錄IP和允許登錄時間的安全限制業務。
IP 分爲內網ip、外網ip，如果設置了，則該用戶只允許在這些ip登錄
2. 原有代碼貼圖
登錄代碼原先已有，這是增加的功能，該同事增加的代碼如下：
圖1：login方法中，判斷是否可以登錄的私有方法調用
圖2、3、4該私有業務實現方法。
3 原有代碼問題分析
從該方法的調用方式，到該方法的實現，代碼都存在不少問題，我先逐一分析，然後再貼上我重構的代碼以及重構的思路。
調用方式
用String匹配的方式判斷，直接用boolean判斷即可。
時間hh:MM的處理 應該寫成工具類，避免重複。
字符串分割的處理 多個地方存在將字符串（逗號分隔）分割爲集合的代碼，應該寫成工具類，可讀性好，並避免重複。
三種比較業務纏繞到一起，業務可讀性差。這裏涉及允許時間判斷、內網ip、外網ip三個業務判斷，但是代碼通過循環纏繞到一起，可讀性差，不夠聚合，難以修改。
多處存在SecureLogEvent的構造（構造安全日誌記錄），並且沒有將關鍵業務數據傳入。
註釋很少，關鍵代碼不容易閱讀。
方法命名不夠準確、明確。
Magic Code太多，應該重構爲常量。
4 重構過程說明
由於重構過程的代碼是反覆修改，所以已經不好拿回，我先說明一下我的重構過程，然後將重構結果代碼貼上，這樣讀者應該可以基本理解了。
先閱讀該部分代碼，觀察那裏存在重複。
將將時間處理分割出來，作爲獨立私有子方法。
寫好後，寫個main函數測試一下，沒問題了就替換原方法中時間處理部分的代碼。
閱讀字符串分割相關代碼，找出其共性，然後寫私有方法、測試、替換。
觀察原先代碼，【允許登錄時間】判斷是在兩重循環裏面進行判斷，但是從業務角度，只要不在允許範圍，哪怕ip允許也是一樣不行的，所以應該單獨判斷，而不是放在循環裏面。
內網ip判斷、外網ip判斷，同理，也應該可以獨立判斷，所以兩重循環就可以拆成兩個獨立的循環了。
業務理清後，代碼層次就清晰了。
然後將日誌增加有價值的業務數據、代碼加上註釋、魔術字重構爲常量等。
將調用處（前面圖1）改爲boolean方式。
將整個規則判斷代碼從CreditController中移出去，新建一個合適的工具類存放，一來減少該Controller代碼，二來以後類似的擴展都已放到該工具類中，職責更加分明。
5 重構後的代碼
圖1：調用處，改爲工具類，並且返回boolean，命名方面可讀性明確，禁止ip和訪問時間，如果返回true，就跳回登錄頁面。
圖2、3：
最上面是常量。
然後下面是目前本類唯一一個公有方法。
先判斷允許方法時間，調用私有方法forbitVisitTimeRange。
然後下面isInside（是否可以內網訪問）、isOutside（是否可以外網訪問）分別判斷（調用checkRange私有方法），去掉了兩重循環。
recordLog寫成私有方法，並允許傳入拼接信息，把有業務意義的關鍵數據也寫到日誌中。
圖4、5、6三個圖。
時間處理：通過ToDay工具類（我的框架自帶）處理，可讀性更好。
逗號分隔的字符串的分割方法，用框架的工具類，並通過兩層的私有方法，讓代碼更容易維護。
寫日誌的私有方法，增加了拼接業務數據字符串的參數供傳入。
6. 總結
避免重複代碼 看到重複代碼，務必想辦法把它抽離出來重用。
善用工具類 無論自己框架的還是第三方開源框架的，不要自己發明輪子，如果沒有，甚至自己寫一個工具方法，這樣可以讓代碼更關注業務。
涉及多重循環時，好好考慮一下是不是一定要這樣做纔可以。能否每個業務一個獨立的子方法？
註釋不能省，而且對於關鍵代碼，有註釋可讀性大大提升。
魔術字要重構爲常量。
寫日誌時，切記不要寫那種沒有參考價值的日誌。你要考慮一下，如果以後業務出錯或者出現意外需要回看日誌時，這些信息夠不夠，能不能讓你足夠的重現當時的場景
推薦閱讀
GitHub 熱榜：標星 1.6w，黑客必看的黑魔法開發指南！
深入瞭解 Json Web Token 之概念篇
Spring 中的 bean 是線程安全的嗎？
最後，推薦給大家一個有趣有料的公衆號：寫代碼的渣渣鵬，7年老程序員教你寫bug,回覆 面試或資源 送一你整套開發筆記 有驚喜哦