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提交规范：
参考：https://www.jianshu.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 就可以了。
