2. 重構概述
1. 項目的整體重構：
- 代碼規范性嚴格要求
- idea級別的警告做到盡可能的優化處理
- 禁止出現冗余重復性代碼，重復即可通過抽象繼承封裝或者設計模塊進行優化。
- 常量命名應該全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長
- 命名符合UpperCamelCase命名風格
- 類名不要以動詞開頭
- 類、類屬性、類方法的注釋必須使用javadoc規范，使用/內容/格式，不得使用//xxx方式和/xxx*/方式，具體參考jdk的注釋
- 代碼幾乎完全基于JAVA8語法實現
- 函數代碼行數不要超過一屏幕的大小，比如100行
- 一行代碼最好不要超過IDE的顯示寬度
- 避免在程序中使用魔鬼數字，必須用有意義的常量來標識
- 代碼抽象和封裝優化
- 核心冗余功能進行抽象和優化
- 整體代碼優化掉35%左右
通過代碼分析工具可以進行對比：
當前版本：
image.png
重構版本：
image.png
對比結果可發現：整體JAVA代碼行數從152000行(不包含order代碼)左右變為111000（包含order整合代碼），代碼整體減少行數超過30%
2. 核心功能重構目標（不對外）：
- 架構層面
- 功能層面
- 代碼層面
3. 代碼分層設計規范：
代碼分層設計規范.png
4. Git提交規范：
參考：http://www.lxweimin.com/p/6eafeb9b1edb
Git每次提交代碼，都需要寫Commit message（提交說明），規范的Commit message有很多好處
- 方便快速瀏覽查找，回溯之前的工作內容
- 可以直接從commit 生成Change log(發布時用于說明版本差異)
Commit message 格式
<type>(<scope>): <subject>
// 注意冒號 : 后有空格
// 如 feat(miniprogram): 增加了小程序模板消息相關功能
scope選填表示commit的作用范圍，如數據層、視圖層，也可以是目錄名稱 subject必填用于對commit進行簡短的描述 type必填表示提交類型，值有以下幾種：
- feat - 新功能 feature
- fix - 修復 bug
- docs - 文檔注釋
- style - 代碼格式(不影響代碼運行的變動)
- refactor - 重構、優化(既不增加新功能，也不是修復bug)
- perf - 性能優化
- test - 增加測試
- chore - 構建過程或輔助工具的變動
- revert - 回退
- build - 打包
image-20201210103450070.png
Commit message 次數盡可能的少
- 代碼邏輯一開始盡可能的考慮清楚，需要改哪塊涉及哪些地方，代碼結構分層等
- 盡可能的本地測試通過后再進行commit代碼，而不是反復提交代碼在測試環境進行驗證再反復修改
- 方便其它人進行代碼review，代碼歷史看起來也比較清晰
禁止git log 中出現不少 "Merge branch ‘xx分支' of ..." 的記錄，造成提交記錄的污染
https://www.cnblogs.com/Sinte-Beuve/p/9195018.html
原因：當多人合作開發一個項目時，本地倉庫落后于遠程倉庫
-
最簡單的方法就是用merge代碼前用idea菜單欄中的update project
- merge ：就是git的合并代碼。遠程代碼在你push之前已經被修改了。就需要先merge。如果沒有沖突，就自動合并修改,否則需要逐一合并
- rebase:拉下來的代碼有沖突，但是不會自動合并。需要你手動合并
-
其它幾種解決方案：
- 如果你使用的是 Git Bash，直接使用 git pull --rebase。如果拉取不產生沖突，會直接 rebase，不會產生分支合并操作，如果有沖突則需要手動 fix 后，自行合并。
- 如果使用的是 GUI，例如 TortoiseGit，可以先 fetch，再手動 rebase 就可以了。
