2019年组织团队成员进行过多次code review，常见出现问题总结如下：

1.变量及命名

1.魔法值

不要使用魔法值，需要使用的常量提前给出定义。

2.命名规范

变量名，方法名，常量等，按照各自规范来，这是基本规范。（可参考：阿里JAVA开发手册-编程规约-命名规范）；

3.枚举使用

有业务含义的常量，要定义为枚举，不要仅仅定义为常量。

比如，借款审核状态，有审核中，被拒绝，被关闭，审核通过等多种状态，代码里做判断时，用ONE,TWO这种去判断，阅读代码时是没法理解业务含义的，还得去查这个的ONE究竟是什么含义，要定义借款审核状态的枚举类使用。

4.异步方法命名

建议异步方法命名添加个async前缀，让上游调用方知道这个方法是个异步方法，以防使用出错。

5.git提交信息

禁止无意义的commit信息，如1，2，update等，没有任何业务含义。

新增功能，修改功能，移除代码，格式化代码，重构，bugfix等，不同类型的操作，要加统一的前缀以区分，否则多分支并行开发时，合并个别提交时，难以摘取；且在code review时，难以区分本次提交的作用和目的，出问题时，回滚提交也难以区分；

每次提交，应该尽量有业务边界的概念，不要在一次pr中，做多件事情；

2.远程调用

1.必须做状态校验

跨服务远程调用时，对于应答结果，上下游必须做好状态码的商定，下游调用时，必须去校验结果的状态，然后再解析处理。

2.NPE判断

不管上游是否做过特殊处理，下游调用时，必须自己做好NPE判断。

3.做好异常处理

跨服务调用，异常高发，要做好异常的处理，是重试，还是根据异常类型做对应处理，需要下游自行做好处理。

4.入参出参记录

调用前后的入参和出参埋点，出现问题可以及时还原案发现场；如果日志量较大，可以按特定比例（可调整）打印，比如只打印1/20日志。

5.尽量少在大循环里做跨服务调用

如果需要在循环中多次调用，建议尝试将单条拉取改为批量拉取，减少调用次数，提高响应速度。

3.异常处理

1.合理使用try catch

区分稳定代码和不稳定代码，对于稳定代码，不需要try , 不要把整个方法的逻辑都放在try里，出现问题时，难以定位。

2.合理使用日志级别

不要全局都使用info级别，出现异常和警告等，使用对应的日志级别，否则出现问题时，本该在error日志中的信息跑到了info中，影响问题排查效率。

3.catch处理

catch中，不要简单的留下个自定义字符串，比如“借款审核失败”；异常发生时，一定要记录异常堆栈，还要记录案发现场的入参出参等必要信息，方便还原案发现场。

要避免，线上出现问题，日志只有一句话，为了排查问题，还得加日志加堆栈，然后发个版。

4.非主流程操作

出现问题不影响主流程的操作，可以放在try catch里，比如向kafka发送打点日志，避免非主流程操作失败，导致主要业务失败。

5.告警机制

部分核心操作，出现问题时，要添加相应的告警机制，比如短信，邮件，钉钉等，开发及时介入解决。

4.BigDecimal使用

1.常量定义

合理使用构造函数，避免构造出精度缺失的常量。

2.精度问题

除法计算时，要使用合理的函数，设置精度，避免无限小数这种结果导致异常。

5.基本规范

1.注释

作者信息，方法注释等，按照规范来，禁止个性化省略，按照开发规范，风格统一。

2.方法大小

适当做好拆分，做好复用，禁止一个方法几百行。

3.文件/图片存储

文件和图片等，数据库存入url时，要存相对路径，不要存全路径。以防图片服务器迁移，切换ip端口时，所有项目的文件图片地址都要修改。

最后更新： 2020年03月20日 10:02

原始链接： https://java4all.cn/2020/01/05/2019代码评审总结/