31、生鮮電商平臺-一次程式碼重構的實戰案例
說明，Java開源生鮮電商平臺-一次程式碼重構的實戰案例，根據實際的例子，分析出重構與抽象，使程式碼更加的健壯與高效。
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.總結
-
避免重複程式碼 看到重複程式碼，務必想辦法把它抽離出來重用。
-
善用工具類 無論自己框架的還是第三方開源框架的，不要自己發明輪子，如果沒有，甚至自己寫一個工具方法，這樣可以讓程式碼更關注業務。
-
涉及多重迴圈時，好好考慮一下是不是一定要這樣做才可以。能否每個業務一個獨立的子方法？
-
註釋不能省，而且對於關鍵程式碼，有註釋可讀性大大提升。
-
魔術字要重構為常量。
-
寫日誌時，切記不要寫那種沒有參考價值的日誌。你要考慮一下，如果以後業務出錯或者出現意外需要回看日誌時，這些資訊夠不夠，能不能讓你足夠的重現當時的場景。
轉載自-- https://www.cnblogs.com/jurendage/p/9143105.html