代码评审应该先看风险

代码评审如果只盯格式、命名和缩进，很容易错过真正重要的问题。风格当然要统一，但评审的第一目标应该是降低上线风险。

先看行为变化

我看评审时会先问：这个改动改变了什么业务行为。新增功能、修改状态流转、调整查询条件、改变权限判断、重写异常处理，这些都比变量名更值得优先关注。

如果行为变化说不清，说明提交本身也可能没有被充分理解。

边界情况包括空数据、重复请求、并发提交、依赖失败、权限不足、历史数据兼容。很多线上问题不是主流程错了，而是边界没处理。

评审时主动问这些问题，比上线后从日志里找原因要便宜得多。

可维护性不是抽象口号。重复逻辑是否能合并，命名是否表达业务，异常是否有上下文，测试是否覆盖关键路径，这些都会影响后续维护成本。

但我不会为了追求漂亮结构做过度抽象。只有当抽象能减少真实复杂度时，它才值得引入。

代码评审应该从风险开始，再到边界，最后看表达。好的评审不是挑刺，而是帮助代码在真实环境里更稳定地运行。