最近抽空使用阿里編碼規約掃描了前陣子擼的碼，發現經常處於一線開發的我們，思維常被局限在局部視角內，低頭走了很長夜路，回首沉思，當時自己是受了什么打擊才能寫出這樣的代碼Σ( ° △ °|||)︴汗。每次重構，都會發現很多可以優化的地方。
需求是這樣的，用戶具備兩種類型等級：通用會員等級 和 prime會員等級。根據該兩種等級 ，及商品的價格碼級別，只有會員的級別達到商品的價格碼級別，才會return true(展示該商品給用戶查看)，否則為false。如用戶為prime會員，則以prime會員級別判斷，否則用通用會員級別判斷。初始代碼如下
代碼很長，一個方法超過80行，會被阿里編碼規約掃出來。。說明下編碼規約不提倡超過80行的原因：java文件通過虛擬機（jvm）生成.class字節碼文件，每次方法被執行，jvm通過解析.class文件成機器語言執行。流程是這樣：java文件->編譯生成.class文件->根據.class文件解析成機器語言執行。當代碼字節小於8000的方法被執行的次數足夠多以后，它會被動態優化並編譯成機器碼執行，執行速度會大大加快，即JIT編譯。而大方法則不會被JIT編譯，這是主要原因（另外可能也考慮到行數過長，不利於以后的維護擴展）。
so。。靜靜思考了下，優化：根據判斷條件組合成key，通過map的組合key去獲得判斷結果的方法，超過80行的大方法重構如下：
