持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第14天，点击查看活动详情
前言
什么是CodeReview ？
代码审查其实是软件开发过程中一个必不可少的环节。
最近我也思考codereview这件事情，作为一个工作很多年的老码农，code review经历过很多次，不同的公司方式风格也不一样。很多团队code review到最后也只是流于形式，还有的把codereview作为diss或者pua对方的点，我觉得这样是很不好的也没有意义的一件事情，比如说团队里面来了新人，对这边代码分层和命名不一样，有些同学摆老资格说这说那扽等。
下面就我带团队工作如何做CodeReview，我自己个人的一些观点
工程架构规范的约定
一些常见的代码工程的领域划分分层，第三方系统调用防腐层划分。比如接口门面模式controller层不能有复杂的逻辑， service层不要写SQL条件的组装等等，出一份约定的文档，作为小组的代码规范即可，code review 大可不需要过多纠结在这个点上，防止丢了西瓜捡了芝麻。
技术方案设计
程序员都知道，真正编码的工作其实占用软件开发过程中的时间不会太多，我觉得不会超过50%， 前期的需求评审， 技术方案设计才是真正需要花时间的地方。核心技术方案的设计，必须要详细的方案设计，比如数据库设计，缓存设计，各个系统交互方式的设计等等。比如让你设计一个大促抢红包活动的一个设计，红包的超发，防资损设计，这些核心模块设计需要重点关注， 当然后面的代码review过程中也需要重点关注的。
单测
写单测其实是一个很好的开发习惯，减少低级的错误，提高代码质量，测试人员有更多的精力放在性能和一些核心的点上。
CodeReview怎么做？
Code Review（代码审查）是软件开发中的最佳实践之一，可以有效提高整体代码质量，及时发现代码中可能存在的问题。包括像Google、微软这些公司，Code Review都是基本要求，代码合并之前必须要有人审查通过才行。
那要怎么去做CodeReview呢？ 一个需求可能上万行代码，合并前让审核人去看每一行代码，并保证review的质量其实很难，效果也是不明显的。估计让阿里多隆大神审查不知道会不会好点。
个人比较倾向的Review的一些方法
1、Review参与的人员
架构师和业务比较熟悉的老员工， review不需要太多人，人多效率不一定高，人多会议时间拉长反而降低review的效果。
一般比较大的业务版本在技术方案评审的时候有一些技术难点，或者架构师和小组的TeamLeader觉得这一块会有一些技术风险的点组织CodeReview会议的时候，重点关注。一些小的迭代，在技术方案评估之后只是一些小crud，我觉得版本小组内相互review一下就Ok了
2、Review的方式 CodeReview的时候让开发任务复述的形式比较好，从逻辑的入口，到核心方案如何设计和实现。一方面也锻炼了开发同学讲解代码的能力。
工具
Sona 和checkStyle 对于相对大的公司团队来说，这两个都很有必要尽可能保证代码风格的统一，减少沟通成本。但是小一点的公司checkStyle可以忽略，但是sona必须需要做一些检查。减少一些低级的错误。
