JAVA代码Review总结

1. 代码Review的目的

一般团队很难在Review中要求极致的代码质量，毕竟是项目而非艺术品。你很难通过Review要求程序进化为完美的程序，很难要求程序员都达到很高的水准，所以常见团队的Review更多的是达成一定的共识，底线是质量可以做到项目要求的高度。而更优秀代码的探讨可以作为锦上添花的讨论，根据情况推荐而不强求。

本文尝试总结下自己评审中遇到的通用问题，项目或业务名称通过简称来替代。

2. 重点Review的点

• 架构是否合理：虽然是在Review代码，其实很多时候我们都是在评判架构是否合理。 比如数据的同步机制是否合理等等
• 跨网络请求：跨网络请求一般是性能占比最高的地方，是否在循环中调用。
• 异常处理：结合业务查看异常处理流程是否正确合理，异常处理是出错的重灾区，需要重点关注。
• 监控日志：程序执行重点痕迹是否得到了妥善记录，辅助排查问题
• 算法效率：算法是否过于复杂

3. 评审中遇到的汇总

• 业务代码中耦合算法：比如「YHQ」系统的代码Review，命中黑名单和业务处理写在了一起，应该抽取黑名单模块；进而黑名单模块可以做成项目无关，整个公司通用。

• 代码实现不符合真实业务：比如「MF」系统的Worker代码review，把不能处理任务的状态直接设置为删除有风险，应该使用中间态暂存处理不了的任务；进一步说这些任务处理是通用的，业务无关的，应该使用通用的任务处理平台。

• 接口返回的出参过大：「HB」系统评审中接口返回使用了内部对象&#