文章 · 工程化
给团队写的一份代码评审清单
评审最容易漏的不是语法，是那些「跑得起来但以后会疼」的地方。把反复出现的问题写成清单，评审时照着过一遍，比依赖记性靠谱得多。
先看边界
- 空值与异常路径是否都有处理，而不是只覆盖了顺利情况
- 并发场景下共享状态有没有被同时改写
- 外部输入有没有做校验，还是直接信任了上游
再看命名与结构
命名能不能让后来的人不点进实现就猜出用途，是这一块唯一的标准。函数超过一屏、参数超过四个、嵌套超过三层，都值得当场提出来。
最后看测试与提交信息
改行为有没有同时改测试，提交信息说的是「为什么」还是只说了「做了什么」。这两条决定了三个月后的人能不能理解这次改动。
评论6
登录后参与评论，你的发言会署上自己的名字。
陈默作者@chenmo·2026-09-10
放在最前面：看到都会回，先谢过各位补充的经验。
孟凡@mengfan·2026-09-11
构建脚本重写那段看着很有共鸣，最花时间的果然还是新旧产物对照。
程野@chengye·2026-09-12
这份清单可以直接拿去做评审模板了，覆盖面挺全。
姜堰@jiangyan·2026-09-13
命名那一条看着简单，但确实是评审里最常被提出来的问题。
童语@tongyu·2026-09-14
边界情况那段写得好，很多问题都是顺利路径跑通了就当完成了。
严冬@yandong·2026-09-15
状态管理这块我更倾向于能不放全局就不放，理解成本差很多。