前言
代码是给机器运行的，但同样也是给人看的，并且随着上线还需要由人来运维。那么写出可扩展、易维护、好读懂的代码就显得非常重要。
对于新人来说，互联网大厂项目开发与平常自己学习的代码还是有很大的差别的。日常学习时候通常只要能运行出结果即可，并不会有其他的要求。也不会说有；PRD评审、研发设计评审、代码开发、代码评审以及中间一些列的提交物，直到测试完成，上线验证，开量对外等等。
一次上线前的代码评审 是通过同事之间互评 针对代码评审提出的几点重要的记录分析给大家
日志该怎么打印？
日志是整个代码开发过程中非常重要的环节，如果日志打的不好，那么遇到的线上bug就没法快速定位，定位不了问题也就没法快速解决问题。直接带来的结果可能包括；客诉更多、资损更大、修复更慢。
如下面这端代码的打印
public Result execRule(RuleReq req) {
try {
logger.info("执行服务规则 req：{}", JSON.toJSONString(req));
// 业务流程
return Result.buildSuccess();
} catch (Exception e) {
logger.error("执行服务规则失败", e);
return Result.buildError(e);
}
}
1：看似没什么问题，但在这段异常代码中，没有打方法的入参信息。如果方法异常时只是抛出一些异常栈信息，那么是很难定位具体的由次调用触发的。
2：另外如果你的系统监控服务，没有类似方法跟踪ID的功能，最好还需要在日志中把本次调用具有标识性的id，作为查询条件打到日志中。
修改后的日志：
public Result execRule(RuleReq req) {
try {
logger.info("执行服务规则{}开始 req：{}", req.getrId(), JSON.toJSONString(req));
// 业务流程
logger.info("执行服务规则{}完成 res：{}", req.getrId(), "业务流程，必要的结果信息");
return Result.buildSuccess();
} catch (Exception e) {
logger.error("执行服务规则{}失败 req：{}", req.getrId(), JSON.toJSONString(req), e);
return Result.buildError(e);
}
}
在异常中打印入参是为了更加方便的定位问题，不需要比对上下文。
IDEA提示
很多时候因为你，走神、疏忽、手滑，写出来的错误代码，IntelliJ IDEA，都会给你警告⚠提示，只是你，没有去看、没有去看、没有去看！
如截图
Idea在警告提示这方面非常优秀，只要你能看得见，按照它的提示修改，就可以减少很多的错误。
代码格式
可能这并不是一个致命的问题，但代码格式化最大的好处是，提升可读性、规整性、以及可以让整组人都在一个标准下执行。因为很多时候一个组的程序员，会在一个类下开发，有人格式化、有人不格式化除了不好看以外，合并代码有时候也会遇到麻烦。
对于严格要自己的程序员来说，代码没有格式化还是很难受的。
单元测试
单测？覆盖率？写代码不是写完就可以了吗？
1：单测完整基本也就是代码的健壮性更好，能把单测写好，基本提交的代码就不会有那么多测试妹子找你聊天。
2：在很多公司中一般都会要求单测覆盖率超过多少，否则是不允许编译提交的，这有插件可以和Jenkins配合使用。
分支规范
在互联网中并不是这样，往往一个系统需要几个人维护，并同时进行开发。一般这里会包括；master分支、test分支、本次需求的分支，有这么多分支怎么用呢，如下；
1：master分支，是主分支，也是上线分支，不允许在上面直接修改代码。
2：test分支，是测试环境分支，每个人都需要把自己开发完的分支，提测后合并到test分支，交由测试验证。
3：需求分支，也是个人开发的分支，同一个需求下，大家在这个分支写代码，当然也可能这个系统模块的分支就一个人在开发。
异常流程
这句话是我经常用的，因为我们编程很多时候都是在处理异常流程，正常流程往往并不难，难的是分析出这段开发的代码有多少异常流程有没有处理。
那么，会有哪些异常呢？
1:支付成功MQ消息发送失败，需要worker补偿
2:PRC接口调用失败，网络超时，实际成功
3:接口幂等性，多次调用结果一致性
等等，这些都是异常流程，尤其在一些交易提现环节，会出现各种异常，那么不可能把这些异常都反馈用户展示到界面。而是要有一些非常友好的提示，并且在服务端的流程里，有一定的补偿机制，来保证最终的调用成功，或者逆反。
代码成坨
CRUD往往可能是因为你的设计，换个人写也许不同
很多时候研发写代码，根本不考虑是否要扩展，总之一个类 + 几十行ifelse，能搞定所有需求。等下次在开发类似的，就粘贴过去再修修补补，能用就行。
SQL性能
select * from table where status = 1 limit 200;
这是一段定时任务扫描库表的SQL，这段sql会定时扫库，将库表中状态是1的扫描出来进行处理，每次扫描200行。你发现有什么问题了吗？
1:扫描必要字段即可，不需要全部字段
2:这段sql会越来越慢，即使状态字段加了索引。因为status并不能大量排掉其他状态字段，随着数据越来越多依然是全表扫描。
好了 至此 代码评审的重要性 点点关注不迷路 老铁们！！！！！
若是行业老司机想利用工作之余时间接单的可+V:（LM_20250118）备注进群
