作为技术团队，我们常说，应该要做代码审核，业内也提供了许多好用的工具。
但真正能坚持执行的团队，我相信并不多。
为什么呢？
也许，你会随口说出如下原因：
- 逐行审核，需较大人力成本
- 审核人，不了解需求，无法对代码进行有效评估
- 哪个环节，代码审核应该介入？测试阶段？此时代码持续更新，与上线版本差异较大。上线前？此时代码已经过完整测试，若需修改，风险较高。
- 审核人编码习惯不同，评审标准差距过大？回字的 N 种写法哪种最好？
- 花这个时间，有什么实际收益呢？
- ...
抛开这些原因，我们先思考一个问题。
你们团队做代码审核的目标是什么？
这里，可以列出很多，比如：
- 标准化编码习惯
- 相互学习
- 找业务逻辑 BUG
- 降低上线风险
- ...
目标不同，侧重点与路径将不同。
这里，我只着重聊「降低上线风险」，因为我认为这个目标，是对于业务，最有价值，同时容易落地的方向。
以个人自身实践经验，「上线风险」不限于包含如下方面：
- 构建逻辑更新
- 全局依赖升级
- 公共方法、组件更新
- 生产环境特殊逻辑更新
- 生产配置检查
- ...
这些方面有一些共同的特点，如，全局影响面广，测试环境难验证，测试同学感知度弱，可快速审核，审核标准较为统一等。
你可能会有疑问，为什么没有「业务逻辑 BUG」。
因为，要发掘这个风险，需要对需求较强的理解，因此不作着重要求。
另一方面，在经过测试阶段后，这部分风险已得到较好控制。
可见，当我们将「降低上线风险」设为目标时，是可以快速、准确、标准的完成审核流程。
也只有，真正达成这个目标，再实现其他目标，无论是对于公司还是个人，才更有实际意义。
作为技术团队，我们常说，应该要做代码审核，业内也提供了许多好用的工具。
但真正能坚持执行的团队，我相信并不多。
为什么呢？
也许，你会随口说出如下原因：
- 逐行审核，需较大人力成本
- 审核人，不了解需求，无法对代码进行有效评估
- 哪个环节，代码审核应该介入？测试阶段？此时代码持续更新，与上线版本差异较大。上线前？此时代码已经过完整测试，若需修改，风险较高。
- 审核人编码习惯不同，评审标准差距过大？回字的 N 种写法哪种最好？
- 花这个时间，有什么实际收益呢？
- ...
抛开这些原因，我们先思考一个问题。
你们团队做代码审核的目标是什么？
这里，可以列出很多，比如：
- 标准化编码习惯
- 相互学习
- 找业务逻辑 BUG
- 降低上线风险
- ...
目标不同，侧重点与路径将不同。
这里，我只着重聊「降低上线风险」，因为我认为这个目标，是对于业务，最有价值，同时容易落地的方向。
以个人自身实践经验，「上线风险」不限于包含如下方面：
- 构建逻辑更新
- 全局依赖升级
- 公共方法、组件更新
- 生产环境特殊逻辑更新
- 生产配置检查
- ...
这些方面有一些共同的特点，如，全局影响面广，测试环境难验证，测试同学感知度弱，可快速审核，审核标准较为统一等。
你可能会有疑问，为什么没有「业务逻辑 BUG」。
因为，要发掘这个风险，需要对需求较强的理解，因此不作着重要求。
另一方面，在经过测试阶段后，这部分风险已得到较好控制。
可见，当我们将「降低上线风险」设为目标时，是可以快速、准确、标准的完成审核流程。
也只有，真正达成这个目标，再实现其他目标，无论是对于公司还是个人，才更有实际意义。
欢迎关注公众号：feniubi
