代码审查不是评审会上的轮流表态而是一场与自己的代码正面相逢的仪式。你坐在屏幕前看着自己三天前写的那段逻辑突然不认识它了——这正是初级开发者最需要的一块镜子。我们不用讨论什么架构、微服务、分布式那些离你尚远。真正能救你的是一份能盯住日复一日小毛病的检查清单。它不是束缚而是一根鞭子抽醒你被IDE自动补全惯坏的直觉。代码审查不是找茬而是提前和未来的自己和解。命名是第一个审查者方法名叫processData变量叫temp入参叫input——这种命名出现在你的PR里等于在向审查者示弱。命名不只是为了让别人看懂更是为了让你自己写下去时不至于在五个data里迷路。审查时先盯名字当一个标识符模糊到需要用注释来补齐含义时它已经污染了整段逻辑。好的命名让代码像句子一样能朗读比如calculateTotalPriceWithTax一眼就知道它做了什么还需要什么参数。如果你是初级开发者请把命名当作品味来训练你的代码就是你的签名。注释的自我修养很多初级开发者喜欢写这样的注释// 这里给订单设置状态然后紧跟一句order.setStatus(1)。这就像在人头上贴一张写着这是一个人的标签。只有一种注释值得存在解释为什么而不是做什么。为什么不能把状态直接改成2因为业务流程有这个限制为什么要延迟两秒因为上游接口需要时间准备。解释动机的注释是宝藏复述行为的注释是噪音。审查代码时把每一条注释都当成对审查者智商的挑衅来重新推敲。如果注释里出现了临时workaround这类词请立刻追问它凭什么临时以及它计划临时多久。异常别吞别裸奔try-catch里吞掉异常就像把厨房里的火警铃声关掉然后继续做饭。你捕获了Exception在catch块里写上log.info(出错啦)这不算处理异常这叫做把问题藏进地窖。最可怕的异常不是没捕获而是被吞掉。审查时凡是catch块为空或只打日志的都值得你停下来问如果这里真的异常了数据会变成什么状态用户会看到什么系统会怎么继续初级开发者常犯的另一个毛病是给方法加上throws Exception把责任全都抛给上层好像这样就很面向对象了。正确的姿势是把异常包装成对调用方有意义的语义错误比如OrderNotFoundException而不是Exception。别让调用方去猜你会在哪里踩雷。封装不要让对象变成公共宿舍一个POJO里定义了一堆public字段或者给你每个字段都配上getter/setter——这不算封装这是把类和结构体混为一谈。很多初级开发者觉得JavaBean就要这样写于是对象的内部状态完全暴露任何外部代码都能随手改amount成负数。把一个对象变成数据袋子等于亲手拆掉封装这堵墙。审查时要问这个类真的需要暴露这个字段吗调用方能否通过一个行为方法比如deposit(money)来改写状态而不是直接setBalance(balance1000)你更希望看到一个对象提供做什么的能力而不是让你看屁股下的数据。流式编程的甜蜜陷阱Java 8的Stream确实漂亮filter().map().collect()一行顶一个for循环。但初级开发者容易走另一个极端为了用Stream而用Stream结果写出一个三百字的链式怪兽里面嵌套了三个lambda和两个flatMap读起来比天书还难。流式操作不是炫技而是让数据管线一目了然。审查时给自己一条规则如果这个流式表达式需要超过两行才写得完或者需要额外加一个注释才能读懂那就把它拆成中间变量甚至退回传统for循环。过度使用链式调用会让代码变成一场行为艺术。行为艺术只适合站在美术馆里欣赏不适合跑在生产环境上。可空性消灭隐形的炸弹Java里最经典的问题就是空指针。你写String name user.getName().trim()结果getName()返回了null于是程序在深夜两点崩给你看。初级开发者可能第一反应是加个if(name ! null)但这样加下去你的代码会像长满刺的仙人掌到处是防御性的判断。真正的高级是让空值无可遁形的设计——用Optional表达可缺失用Objects.requireNonNull在源头拦下非法输入。审查时看到方法返回一个可能为null的集合你该建议返回空集合看到参数不该为null却没有任何检查你该建议加上NonNull注解或校验。缺少final修饰的变量是给未来的自己埋雷——不是所有引用都必须可变能声明成final的地方就把它焊死。测试是设计反馈不是绩效指标你写了一段代码测试覆盖率达到90%但测试全是验证这个方法没有抛异常——这种测试有什么价值测试的价值在于能证明你的代码能坏而不是能跑。好的测试应该在修改业务逻辑时立刻变红提醒你破坏了什么约束差的测试则永远绿灯让你以为一切正常。审查时先不看覆盖率数字而是看断言。如果测试里只有一个assertTrue(true)或者断言的是方法的内部实现而非法行为结果那这些测试就是表演。100%覆盖率的测试可能只是表演而断言的缺失才是真正的裸奔。你应该写出如果这个需求被理解错了测试会怎么失败——能回答这个问题的测试才算有分量。性能的直觉不靠谱基准测试才算数初级开发者最容易犯两种病一种是不管三七二十一所有数据先扔数据库循环查询另一种是被“性能优化”洗脑为了一个只运行一次的逻辑硬造一个单例池。审查时不要张口就说“这里慢”而是要问你量过吗瓶颈到底在哪性能敏感处先做基准测试再谈优化。有时候一个JVM预热和连接池配置就解决了99%的慢问题你却去优化循环里的字符串拼接——花大力气省下几毫秒而真正拖垮系统的是那几次磁盘IO。保持简单清晰让性能在基准测试的驱动下自然产生而不是靠想象堆砌。记住可读性就是第一性能因为没人能优化自己看不懂的代码。提交信息是你的简历你的代码审查不只是看代码还要看提交信息。一个写着update的提交和另一个写着fix order.totalPrice overflow when discount exceeds 100%的提交哪个更有价值提交信息是写给别人看的墓志铭。它要能回答三个问题这段改动解决了什么问题为什么用这种方式解决还有什么别的方式没选初级开发者往往把提交当成CtrlS每天留下几十个update的尸体等三个月后回看时连自己都不知道当时改的是什么东西。审查时要养成习惯每个提交必须独立、有完整信息、可构建通过。如果一个提交混进了格式化、重构、新功能三件事请把它拆开那是给自己和审查者的精神污染。清单最终是为了遗忘这份清单看起来条目繁多但它的终极目标是让你不用再依赖它。当命名、注释、异常、封装、流式、可空性、测试、性能、提交信息都成为你的肌肉记忆你就不再需要逐条对着检查了。那时你写出的代码不需要自我辩解就能自己说话。真正的代码审查发生在你敲下每个字符的瞬间而不是PR打开之后。初级开发者请放心这个阶段会很快过去前提是你真的愿意在每一次commit前拿出两分钟像对待一场考试那样审视自己的代码。这份清单是你的脚手架而不是你的终点。 
长河君 · 2026/8/7 2:54:00 · 阅读 1.2k 写给初级Java开发者的代码审查清单
代码审查不是评审会上的轮流表态而是一场与自己的代码正面相逢的仪式。你坐在屏幕前看着自己三天前写的那段逻辑突然不认识它了——这正是初级开发者最需要的一块镜子。我们不用讨论什么架构、微服务、分布式那些离你尚远。真正能救你的是一份能盯住日复一日小毛病的检查清单。它不是束缚而是一根鞭子抽醒你被IDE自动补全惯坏的直觉。代码审查不是找茬而是提前和未来的自己和解。命名是第一个审查者方法名叫processData变量叫temp入参叫input——这种命名出现在你的PR里等于在向审查者示弱。命名不只是为了让别人看懂更是为了让你自己写下去时不至于在五个data里迷路。审查时先盯名字当一个标识符模糊到需要用注释来补齐含义时它已经污染了整段逻辑。好的命名让代码像句子一样能朗读比如calculateTotalPriceWithTax一眼就知道它做了什么还需要什么参数。如果你是初级开发者请把命名当作品味来训练你的代码就是你的签名。注释的自我修养很多初级开发者喜欢写这样的注释// 这里给订单设置状态然后紧跟一句order.setStatus(1)。这就像在人头上贴一张写着这是一个人的标签。只有一种注释值得存在解释为什么而不是做什么。为什么不能把状态直接改成2因为业务流程有这个限制为什么要延迟两秒因为上游接口需要时间准备。解释动机的注释是宝藏复述行为的注释是噪音。审查代码时把每一条注释都当成对审查者智商的挑衅来重新推敲。如果注释里出现了临时workaround这类词请立刻追问它凭什么临时以及它计划临时多久。异常别吞别裸奔try-catch里吞掉异常就像把厨房里的火警铃声关掉然后继续做饭。你捕获了Exception在catch块里写上log.info(出错啦)这不算处理异常这叫做把问题藏进地窖。最可怕的异常不是没捕获而是被吞掉。审查时凡是catch块为空或只打日志的都值得你停下来问如果这里真的异常了数据会变成什么状态用户会看到什么系统会怎么继续初级开发者常犯的另一个毛病是给方法加上throws Exception把责任全都抛给上层好像这样就很面向对象了。正确的姿势是把异常包装成对调用方有意义的语义错误比如OrderNotFoundException而不是Exception。别让调用方去猜你会在哪里踩雷。封装不要让对象变成公共宿舍一个POJO里定义了一堆public字段或者给你每个字段都配上getter/setter——这不算封装这是把类和结构体混为一谈。很多初级开发者觉得JavaBean就要这样写于是对象的内部状态完全暴露任何外部代码都能随手改amount成负数。把一个对象变成数据袋子等于亲手拆掉封装这堵墙。审查时要问这个类真的需要暴露这个字段吗调用方能否通过一个行为方法比如deposit(money)来改写状态而不是直接setBalance(balance1000)你更希望看到一个对象提供做什么的能力而不是让你看屁股下的数据。流式编程的甜蜜陷阱Java 8的Stream确实漂亮filter().map().collect()一行顶一个for循环。但初级开发者容易走另一个极端为了用Stream而用Stream结果写出一个三百字的链式怪兽里面嵌套了三个lambda和两个flatMap读起来比天书还难。流式操作不是炫技而是让数据管线一目了然。审查时给自己一条规则如果这个流式表达式需要超过两行才写得完或者需要额外加一个注释才能读懂那就把它拆成中间变量甚至退回传统for循环。过度使用链式调用会让代码变成一场行为艺术。行为艺术只适合站在美术馆里欣赏不适合跑在生产环境上。可空性消灭隐形的炸弹Java里最经典的问题就是空指针。你写String name user.getName().trim()结果getName()返回了null于是程序在深夜两点崩给你看。初级开发者可能第一反应是加个if(name ! null)但这样加下去你的代码会像长满刺的仙人掌到处是防御性的判断。真正的高级是让空值无可遁形的设计——用Optional表达可缺失用Objects.requireNonNull在源头拦下非法输入。审查时看到方法返回一个可能为null的集合你该建议返回空集合看到参数不该为null却没有任何检查你该建议加上NonNull注解或校验。缺少final修饰的变量是给未来的自己埋雷——不是所有引用都必须可变能声明成final的地方就把它焊死。测试是设计反馈不是绩效指标你写了一段代码测试覆盖率达到90%但测试全是验证这个方法没有抛异常——这种测试有什么价值测试的价值在于能证明你的代码能坏而不是能跑。好的测试应该在修改业务逻辑时立刻变红提醒你破坏了什么约束差的测试则永远绿灯让你以为一切正常。审查时先不看覆盖率数字而是看断言。如果测试里只有一个assertTrue(true)或者断言的是方法的内部实现而非法行为结果那这些测试就是表演。100%覆盖率的测试可能只是表演而断言的缺失才是真正的裸奔。你应该写出如果这个需求被理解错了测试会怎么失败——能回答这个问题的测试才算有分量。性能的直觉不靠谱基准测试才算数初级开发者最容易犯两种病一种是不管三七二十一所有数据先扔数据库循环查询另一种是被“性能优化”洗脑为了一个只运行一次的逻辑硬造一个单例池。审查时不要张口就说“这里慢”而是要问你量过吗瓶颈到底在哪性能敏感处先做基准测试再谈优化。有时候一个JVM预热和连接池配置就解决了99%的慢问题你却去优化循环里的字符串拼接——花大力气省下几毫秒而真正拖垮系统的是那几次磁盘IO。保持简单清晰让性能在基准测试的驱动下自然产生而不是靠想象堆砌。记住可读性就是第一性能因为没人能优化自己看不懂的代码。提交信息是你的简历你的代码审查不只是看代码还要看提交信息。一个写着update的提交和另一个写着fix order.totalPrice overflow when discount exceeds 100%的提交哪个更有价值提交信息是写给别人看的墓志铭。它要能回答三个问题这段改动解决了什么问题为什么用这种方式解决还有什么别的方式没选初级开发者往往把提交当成CtrlS每天留下几十个update的尸体等三个月后回看时连自己都不知道当时改的是什么东西。审查时要养成习惯每个提交必须独立、有完整信息、可构建通过。如果一个提交混进了格式化、重构、新功能三件事请把它拆开那是给自己和审查者的精神污染。清单最终是为了遗忘这份清单看起来条目繁多但它的终极目标是让你不用再依赖它。当命名、注释、异常、封装、流式、可空性、测试、性能、提交信息都成为你的肌肉记忆你就不再需要逐条对着检查了。那时你写出的代码不需要自我辩解就能自己说话。真正的代码审查发生在你敲下每个字符的瞬间而不是PR打开之后。初级开发者请放心这个阶段会很快过去前提是你真的愿意在每一次commit前拿出两分钟像对待一场考试那样审视自己的代码。这份清单是你的脚手架而不是你的终点。