一次代码评审，差点过不了试用期：CodeGuide 拆解 Java 新人必踩的 10 个代码评审避坑点

文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本文以 CodeGuide 仓库中《一次代码评审差点过不了试用期》一文为主线系统拆解互联网大厂代码评审中最常见的 10 个问题点——从日志规范、IDEA 提示、分支规范到 SQL 性能与异常流程并结合仓库内 p3c 插件原理、真实研发事故与上线流程文档做源码级佐证。读完本文你将掌握一套可直接用于日常开发的代码评审自查清单知道哪些写法会在评审中被点名、如何整改才能写出可扩展、易维护、好读懂的生产级代码。一、前言代码是给机器运行的更是给人看的“好的代码往往也很好看”。代码是给机器运行的但同样也是给人看的并且随着上线还需要由人来运维。因此写出可扩展、易维护、好读懂的代码就显得非常重要。对于新人来说互联网大厂的项目开发与平常自己学习代码有很大差别。日常学习时通常只要能运行出结果即可不会有其他要求而在大厂中一个需求会经历PRD 评审 → 研发设计评审 → 代码开发 → 代码评审 → 测试完成 → 上线验证 → 开量对外的完整链路《谁说明天上线这货压根不知道开发流程》 对研发、测试、上线的阶段衔接做了详细拆解。很多新人刚从学校毕业或者从小公司进入大厂在规范制约下会有些不习惯甚至犯错误。为了让大家更好地规避这些问题本文整理了代码评审中最常见的 10 个点配合仓库中的真实案例与源码佐证逐一给出整改方案。二、场景还原谢飞机的第一次代码评审新人“谢飞机”入职没多久兴奋地写着 leader 给的需求恰巧组长走过来“飞机带着你的电脑跟我来会议室做下代码评审。”leader飞机你这代码咋这么粗鲁这日志打的上线后出了问题你能查到原因吗leader还有这这 IDEA 都提示你了都报黄色了你怎么不看看。还有这代码也不格式化一个月后它认识你你还认识它吗。leader给你发的入职编码规范看了飞机哦看一些写的时候忘了。写代码不是以完成功能就算完事还需要写得漂亮。评审后飞机坐回工位收起了躁动的心安心熟读手册并练习。下面这 10 个评审点就是“谢飞机”们最容易被点名的位置。三、代码评审 10 大高频问题与整改方案1. 日志规范入参、出参、异常一个都不能少日志是整个代码开发过程中非常重要的环节。如果日志打得不好线上 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); } }看似没什么问题但在这段异常代码中没有打方法的入参信息。如果方法异常时只是抛出一些异常栈信息很难定位到是具体哪次调用触发的。另外如果系统的监控服务没有类似方法跟踪 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); } }整改后就可以非常方便地查询问题例如搜索执行服务规则100098921那么这一次调用的一整串信息就都能搜索出来了。关键要点有三在异常中打印入参是为了更加方便地定位问题不需要比对上下文带上本次调用的标识性 id业务单号、用户 id 等为链路检索提供条件打日志还有很多技巧但所有日志的目的都是为出问题时能快速定位注意不要打太多精简好用即可。2. IDEA 提示看得见就改得掉别等评审才后悔很多时候因为走神、疏忽、手滑写出来的错误代码IntelliJ IDEA 都会给出警告提示只是你没有去看。IDEA 在警告提示方面非常优秀只要你能看得见按照它的提示修改就可以减少很多的错误。如果还希望有更强的提示可以安装p3c 插件基于《阿里巴巴 Java 开发手册》的规约插件帮你检查代码错误。而 p3c 插件之所以能“检查出你的问题”其底层原理在仓库的 《p3c 插件是怎么检查出你那屎山的代码》 中有完整拆解几个关键事实如下插件入口是 action 配置p3c 在p3c.xml中注册了AliP3CInspectionAction绑定编码规约扫描菜单与快捷键shift ctrl alt J并将操作挂载到 MainToolBar、ProjectViewPopupMenu 等位置扫描动作基于 IDEA 的 Inspection 机制AliInspectionActionkotlin 编写通过actionPerformed获取工程、类、文件等信息筛选出AliBaseInspection类型的检查器后执行doInspections规约实现基于 PMDp3c-pmd 是基于 pmd-java 的静态代码检查PMD 用 JavaCC JJTree 把 Java 代码转换成 AST 语法树再通过自定义规则继承AbstractJavaRule重写visit方法遍历 AST 找出问题模式规则可自定义、可测试自定义规则类在ali-naming.xml中配置rulepriority message还可以直接用PMD.main(str)传入待检查文件与规则配置做单元测试验证。也就是说你在 IDEA 里看到的每一条黄色警告或 p3c 报错背后都是一条规则 一棵 AST 的静态分析结果。理解这一点就能明白“按提示修改”不仅是修代码更是在对齐团队的编码规约。3. 代码格式让整组人在一个标准下执行代码格式化可能并不是一个致命的问题但它最大的好处是提升可读性、规整性以及可以让整组人都在一个标准下执行。因为很多时候一个组的程序员会在同一个类下开发有人格式化、有人不格式化除了不好看以外合并代码时也会遇到麻烦。对于严格要求自己的程序员来说代码没有格式化是很难受的——看一段代码只要发现差一个空格位置都知道这是格式化还是没格式化。规范做法是统一使用 IDEA 的Code → Reformat Code或快捷键并在团队内约定好统一的代码风格配置确保提交前代码已经过格式化。4. 单元测试写完只是开始跑通所有流程才算完“单测覆盖率写代码不是写完就可以了吗”——当然不是。你写的代码需要保证它能跑通你所有的流程节点确保这份功能没有问题才能提交给测试否则来回反复耗时耗力。这就是写单测的目的甚至好一点的研发可以通过单测驱动开发在这个阶段把一些共用的方法合并、抽离避免过多的冗余方法。单测完整基本也就意味着代码的健壮性更好。能把单测写好基本提交的代码就不会有那么多测试妹子找你聊天。在很多公司中一般都会要求单测覆盖率超过某个阈值否则不允许编译提交这有插件可以和 Jenkins 配合使用。5. 分支规范master、test、需求分支各司其职可能有些人看到“分支规范”根本没有感觉因为他们开发的项目较小没有多人开发上线周期也短也不会在开发中添加需求。但在互联网中并不是这样往往一个系统需要几个人维护并同时进行开发。一般会包括 master 分支、test 分支、本次需求的分支用法如下master 分支主分支也是上线分支不允许在上面直接修改代码test 分支测试环境分支每个人都需要把自己开发完的分支提测后合并到 test 分支交由测试验证需求分支个人开发的分支同一个需求下大家在这个分支写代码也可能这个系统模块的分支就一个人在开发。重点如果有人不遵守分支规范或者压根没概念把自己的需求代码写在 test 分支上并且多次修改提交都在 test 分支写那就危险了严重会耽误上线原因有三test 分支是由大家把各自代码合并过来共用的会包含 2 个或更多并行需求。当你需要上线时需要把自己的代码合并到 master但 test 分支代码是不能合并到 master 的——那么多未知的内容根本不在上线范围那么你想上线又不能避开 test 分支就需要把你写的代码重新粘贴过去这个时间成本非常大test 分支还随时有被删除重新拉的可能如果有人通知大家删除重新拉你的代码就会丢失。6. 夹带需求哪怕你是好心也会办了坏事“提交测试但还藏一个需求”。研发开发需求代码时有时候会额外加一些其他代码而且这些代码可能跟本次需求并没有关系。为什么会这样以前留下来的 bug想修复下但忘记告知测试在开发这个需求时其他产品又找过来让加功能并说功能很小没有发邮件通知相关测试人员看到某块以前写的代码太乱了就想着优化下自信心很高不必告诉测试。这时候你提交的代码如果不在测试范围又出了问题只能研发自己扛。并且在所有的研发团队几乎是不允许夹带需求上线的这样的做完了不算功劳做出了问题还会被骂。所以千万不要私自夹带哪怕你是好心7. 异常流程幂等性与补偿机制是生产代码的底线“擦屁屁的纸80% 的面积都是保护手的”这句话很形象——我们编程很多时候都是在处理异常流程正常流程往往并不难难的是分析出这段开发的代码有多少异常流程、有没有处理。那么会有哪些异常呢原文档举了三个典型场景支付成功 MQ 消息发送失败需要 worker 补偿RPC 接口调用失败网络超时但实际成功接口幂等性多次调用结果一致性。尤其在一些交易、提现环节会出现各种异常。不可能把这些异常都反馈到用户界面而是要有一些非常友好的提示并且在服务端的流程里有一定的补偿机制来保证最终的调用成功或者逆向回滚。这一点在仓库的 《握草这些研发事故 30% 我都干过》 中有一个非常典型的事故案例作为印证事故现象用户积分多支付造成批量客诉当天紧急排查修复并给用户补充积分事故原因抽奖流程通过 RPC 接口扣减用户积分扣减成功后抽奖。但当天 RPC 服务不稳定造成 RPC 实际调用成功、返回却超时失败而调用 RPC 接口的 uuid 是每次自动生成的不具备调用幂等性所以造成了积分多扣事故整改改为先生成待抽奖的抽奖单由抽奖单 ID 调用 RPC 接口保证接口幂等性RPC 接口失败时由定时任务补偿方式执行抽奖。整改后补偿任务每周仍发生 1~3 次恰恰证明了 RPC 接口确实存在可用率问题也说明这个流程隐患早已存在。结论很明确调用的接口、发送的 MQ 并不一定会每次都成功一定要做好幂等性以及失败后的补偿把整个技术实现流程做得更加完善。8. 代码成坨一个类 几十行 if-else能搞定所有需求吗“CRUD 往往可能是因为你的设计换个人写也许不同”。很多时候研发写代码根本不考虑是否要扩展总之一个类 几十行 if-else 能搞定所有需求等下次开发类似的就粘贴过去再修修补补能用就行。缺少写出良好代码的研发一方面是经历有限另一方面是学了很多理论但不好落地——比如设计模式自己实际写代码时还是很晕。针对“代码成坨”的问题仓库里恰好有整套体系化的学习资源《重学 Java 设计模式》 系列从实际开发业务中抽离出交易、营销、规则引擎、中间件、框架源码等 22 个真实场景详见 README.md 的项目介绍对工厂方法、抽象工厂、建造者、策略、责任链、观察者等模式逐一做实战拆解。代码评审中“代码成坨”的反面就是用设计模式把可变的业务规则抽离成可扩展的结构而不是把逻辑全部堆在 if-else 里。9. SQL 性能定时任务扫库的两种致命问题select * from table where status 1 limit 200;这是一段定时任务扫描库表的 SQL定时扫库将库表中状态是 1 的数据扫描出来处理每次扫描 200 行。你发现有什么问题了吗扫描必要字段即可不需要全部字段select *会把无关的大字段也捞出来这段 SQL 会越来越慢即使状态字段加了索引。因为status并不能大量排掉其他状态字段随着数据越来越多依然是全表扫描。怎么优化呢其实也比较简单先根据状态查询到符合条件的最小 id之后在 SQL 的查询条件中添加id xx即可避免每次都从表头开始扫描。例如改成“先取最小 id再按id 最小id AND status 1 limit 200滚动扫描”的思路。另外如果任务需要多个 worker 扫描、增加效率可以增加“门牌号”设计按 id 取模或分段划分扫描范围让多个 worker 并行消费不同的数据段提升整体扫描效率。10. 结伴编程及早断奶学会自己攻克评审代码最后想说说“陪伴式开发”。这可能不是结伴编程、不是共同合作而是一个研发需要另一个研发不断地提供帮助。有时候可能就是很简单的问题也不想查或者说没有意识去查只是问。业务开发的过程只要把流程定下来、研发设计评审完其他开发过程中遇到的小点并不难只要查一查就可以搞定。当然也不是说完全不能问只不过特别普遍、简单的代码问题自己搞定就可以了。但这个时候还像保姆似的陪伴就会拖累整个团队的进展最终大家都需要扛起那个慢的。所以如果你是那个需要陪伴的要及早断奶学会自己攻克快速成长而如果你是那个卷纸、可哪擦屁股的要把卷纸传递给他。一个人擦一次是能力体现反反复复擦一个人就惹屎上身了。四、总结把评审点变成日常习惯以上介绍了代码评审中涉及到的比较常见的点基本也是很多研发容易忽略和犯错误的地方。这些问题点单独拿出哪一个看都不大但运行在代码中却都有可能发生致命或者麻烦的事情。想让自己能把代码写好就不只面试时候“造飞机”的回答——什么时间复杂度、什么可重入锁、什么红黑树、什么 DDD只要你不能正确地落地和运用这些技术说得再多都是空谈。结合本文与仓库配套文档可以沉淀出这样一份自查清单评审点自查动作日志规范入参、出参、异常是否齐全是否带标识性 idIDEA 提示黄色警告是否清零p3c 扫描是否通过代码格式提交前是否统一格式化单元测试是否跑通所有流程节点覆盖率是否达标分支规范需求代码是否只在需求分支开发、按流程合并夹带需求是否有超出本次需求范围的代码异常流程幂等性、超时补偿、失败逆向是否覆盖代码成坨是否用设计模式抽离可扩展结构而非堆 if-elseSQL 性能是否select *、是否随数据量退化全表扫描结伴编程简单问题是否自己检索解决多学一些、多看一些、多问一些没有坏处但要自己能成长把吸取到的经验心得运用到业务开发中写出可扩展、可维护的代码才能让自己真的升职加薪也能让既有留下的本事也有出去的能力。延伸阅读仓库内代码评审原始文档 | p3c 插件原理拆解 | 研发事故复盘 | 研发上线流程赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐VirtualApp代码质量评审定期进行代码评审VirtualApp代码质量评审定期进行代码评审 代码质量是开源项目长期健康发展的基石尤其对于VirtualApp这样涉及Android沙盒技术的复杂项目。移动开发虚拟化代码评审不再踩坑用Trae Agent实现自动化情绪检测代码评审不再踩坑用Trae Agent实现自动化情绪检测 你是否遇到过这样的场景团队成员因代码评审意见产生误解简单的技术讨论演变成情绪对抗根据Stack人工智能大模型AI AgentAgent 框架代码智能体CLI工具调用Data-Science-For-Beginners 实战用 EDA 探索纽约出租车小费数据的季节性规律Data Science For Beginners 实战用 EDA 探索纽约出租车小费数据的季节性规律 导读 本文围绕 Data Science For B数据科学教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考