代码审查
官网：https://haomo-tech.com
作者：胡小根
版本：v0.0.1
代码审查要素：
- 流程
- 规范
- 版本命名规范
- 目录结构规范
- 代码规范
- 内容
- 工程结构
- 版本管理
- 代码质量
- 领域驱动设计
- 设计模式
- SOLID原则
- 工具
1 审查目的
- 保证项目质量
- 传授编程经验
2 审查工具
商用
- Jetbrains Upsource 公司采用的便是此工具
- Atlassian Crucible
免费
- ReviewBoard
- Facebook Phabricator
- Codestriker
- Groogle
- Rietveld
- JCR（Java Code Reviewer）
- Jupiter
- ReviewClipse
2 审查流程
审查遵循以下流程：
- 每1-2周安排一次审查。建议：每周做一次代码审查。
- 审查组的所有参与成员，应该相关模块的成员。例如后端和前端就不适合在一个组。
- 审查前1天：所有人员提交最新的代码；
- 审查前1小时：将审查点准备好；
- 审查中：做好记录；
- 审查后：
3 审查内容
3.1 代码风格规范
3.2 代码仓库管理
3.2.1 分支管理
常用远程分支： master dev prd
tag管理： 凡是部署版本给客户验证的，均应该打上tag以进行标识。
3.2.2 版本规范参考
<major>.<minor>.<patch>-<stage>.<num>
以上：
- major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
- minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。
- patch ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。[1]
- stage ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
例如：
0.9.0
1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-rc.1
1.0.0
1.0.1
3.2.3 commit管理
完成某一个issue之后，commit的内容类似："解决#28 修复xxx问题"