代码评审怎么做才有价值：先看意图，再挑细节

代码评审是团队协作的重要环节，但低效的评审常常变成互相挑毛病。有价值的评审应当先理解改动要解决的问题，再检查实现是否与之匹配，最后才看细节。

第一步是看提交说明。说明写清楚背景、目标与影响范围的改动，评审者能快速进入上下文；说明含糊的改动，即使代码正确，也值得先澄清需求。

第二步是核对边界条件。测试用例是否覆盖了异常输入、并发与失败恢复，往往比主路径更关键。评审时多问一句“如果这里出错会发生什么”，能提前拦截大部分隐患。

第三步才是风格与细节。命名、缩进与注释问题可以交给工具自动检查，人工精力应放在逻辑与设计层面，否则评审很快变成疲劳的机械工作。

最后给出可执行的结论。明确的通过、修改或讨论建议，比笼统的“再看看”更有助于推进。好的评审最终沉淀的是团队的共同认知，而不是一长串修改意见。