我发现平常code review问题主要体现在两个方面：一个是编码习惯问题，另一个是编码质量的问题。编码习惯主要有日志编写、代码注释以及编码风格的问题，而编码质量则与很多方面相关，比如轮子的使用、数据交互、逻辑精简程度等等。

编码习惯问题：

互不相干的change不要放在一个commit中，避免review者不明其意，也可方便后续可能发生的cherry pick。 将风格问题消灭在本地，像换行，空格，javadoc等问题，都可以借助工具来避免，例如IDEA的Alibaba Java Coding Guidelines插件。 重构代码的change不要加入逻辑的变更。 涉及到结构或数据库设计相关的改动，先把设计基础部分编写好，提交一版review，避免做的差不多后发现设计存在缺陷再修改代价就很高。 方法体太长，可考虑抽取成小方法。 注释与实现不符，这对后期维护人员是个伤害。 日志缺失或缺少重要上下文信息输出，一旦发生问题，线上排查困难。 非复杂逻辑，推荐使用stream api，而不是for循环。 尽早结束分支流程，保证方法中主干逻辑清晰。 api路径定义完整mapping在方法上，避免拆开一部分到类上，以方便搜索（controller类一部分，方法一部分） 编码质量问题： 重复造轮子的问题，常见工具类使用不到位，经常自己写方法实现。比如Apache commons，Google Guava等；另一个是共用的业务代码，如果不熟悉容易出现多个版本的实现，后期维护成本上升。 公共数据使用不充分，存在重复调用的情况，而不是一次调用，多次使用，尤其是与其它业务交互的调用损伤更大。（像保险业务那边，经常需要通过接口调用获取用户信息，如果每个人都只管自己的实现，不管其它既有代码内部逻辑，需要信息就粗暴的调用一次，一个前端接口，可能会出现N次用户中心接口请求） 参数过多时，可转化为对象传参。 代码命名，未能见名知意，这其实是一个老生常谈的问题，想个优雅的名字是多么的重要。 多余代码，并无实际意义。比如有些情况下，先查询，再更新，其实完全可以采用以条件更新的方法。 校验逻辑要提前，防止做无用功。 前后逻辑重复，比如Controller中作必输校验，Service无须再次校验。 虽标记了FIXME/TODO，却实际许久未修复。 异常信息处理欠妥当，直接将错误堆栈信息返给前端用户，体验太差。此类信息需要包装，尽量对用户友好。 包结构、文件目录结构、以及功能方法所在的类等安排不合理，存放错乱，让后续开发人员难以理解。 数据库操作先select再update时有时间空档，容易被其它线程更改数据。应直接采用update的方式直接拿数据。 涉及分布式系统间交互数据时，需要有补偿机制来保证数据的最终一致性。也就是说非正常情况下的保障措施缺失。（像活动和保险那边，其实都有这样的处理） 方法定义中的形参取名一定要让使用者知道这个参数要传什么内容，不要用笼统的名字。http://reviewboard.56qq.com/r/27139/#comment14294 使用mybatis-plus更新数据时，应该构造新的对象去更新，而不是在老的对象上修改属性值再传入更新（即只更新需要变化的字段） domain定义字段时，不要使用基本类型，因为在查询数据时构造查询对象，基本类型会有默认值，导致原本没有设置该字段查询条件，但实际它是有值的，使得查询结果非预期。 开发自用的调试接口安全性问题，例如手动触发定时任务之类的接口，不要裸奔，至少需要时signApi。 实现是否具有扩展性，尽量不要出现定制化的硬代码。 api变更要考虑兼容问题，例如返回数据结构发生变化，那么就要考虑是否要保留老接口不变，新结构在新接口上体现。 测试代码问题： 测试数据不具有代表性，导致主线功能测试覆盖不到，真正提交测试时很容易暴露出问题。 单元测试代码没有断言，只是单纯地走一遍代码，实际执行成功没有都不知道。 单元测试还在调用真实服务，尤其是调用第三方服务。 怎么做好code review？ 在有限的工作经验和各个团队切换的经历来看，我觉得code review能做好的几个关键因素：

善用工具，把风格问题消灭在本地，及时解决IDE就能提示你的问题。

checkList很有用，避免review时一头雾水，但需要在实践中逐渐累积总结。 提交适量的代码review，代码太多，容易让review者丧失耐心，也容易遗漏问题。 团队的支持。 我code review的过程： 粗读：先看commit message，大概知道在做什么，然后扫描一遍代码量，改了哪些文件，是不是大量新增？ 抽取重点：粗读之后大概明白编码人的目的，那么就抽取重点来看，看下是否在设计上合理。 细读：重点节点浏览一遍没有太大问题，那么可以顺着设计思路看一遍代码，或者从每个文件开始浏览，根据脑袋中缓存的checkList检查代码问题。 如果是自己熟悉的业务，会再确认业务逻辑上是否存在明显不对的地方，有没有更好的办法；对老功能是否有侵害。 需要避免的做法： 作为reviewer，不要刻意寻找代码的bug：有些代码的逻辑是比较复杂的，如果是很容易发现的错误，在编码的过程大多数都会发现，那么剩下的不容易发现的错误可以交给测试人员去发现；如果参与者刻意去找Bug将会是顾此失彼，忽略更重要的东西，花费更多的时间，当然如果有些Bug你一眼就看到了就再好不过了。 reviewer最好不要自己都没想明白就提意见：如果自己没有想明白的事情就去提意见，那么评审者反问的时候会浪费大家的时间；reviewer可以先将自己的想法大致记下来，在有空闲的时间想清楚了在提给评审者也是节省时间的办法。 不要认为只有@了自己的才可以review，我觉得只要有空，都可以取review团队所有成员的代码。 code review后带来的实际好处： 自身能力的提升，相比于自己闷声写代码，把代码拿出去供大家品读，吸收他人的技巧；编程的时候会跳出来思考，这样做是不是最好。 团队效率提升，review让团队成员都互相熟悉各自负责的部分，定位问题，开发新功能时更迅速。 让单元测试成为了习惯，没人监督的话潜意识会偷懒，会越来越随意，有了review，会自觉地让代码加上单元测试表示让review人更放心。 偶尔休假，不用担心总有人，因为团队其它成员也可以协助你的部分。