核心原则：评审的目的是提升代码质量，不是展示个人优越感
情绪是代码评审最大的敌人。 一旦对方感到被攻击，所有技术建议都会失效。
“提问式建议”话术模板：用好奇代替批评
❌ 伤人式批评：
“你这命名太烂了，谁能看懂？”
“这设计模式用得不对，应该用XXX。”
✅ 提问式建议：
“这个变量名 data，我看了上下文不太确定它具体指代什么，如果我们改成 userProfileCache，会不会让后续维护的同学更一目了然？”
“这个方法现在负责了数据获取、处理和校验，如果未来校验规则变多，会不会让这个方法变得比较臃肿？我们在考虑单一职责上，有没有可能把它拆分成两个更内聚的方法？”
分层反馈法：区分“风格”与“风险”
第一层：风格问题（可妥协，标记为“建议”）
· 范围：命名偏好、简单格式、非核心的代码结构。
· 话术：“我个人习惯在这里加个空行让逻辑块更清晰，你觉得呢？如果觉得没必要我们就保持原样。”
（潜台词：这不是对错问题，是偏好问题，你才是这块代码的主人。）
第二层：潜在风险（需讨论，标记为“疑问”）
· 范围：可能的内存泄漏、并发问题、边界条件缺失、性能隐患。
· 话术：“这个循环里的集合操作，如果遇到非常大的数据量，有没有可能引起性能问题？我们是否需要提前考虑分页或懒加载？”
“这里直接调用了外部服务，如果服务超时或返回异常格式，我们的降级和容错机制是怎样的？”
第三层：实质性错误（必须修改，但语气仍可缓和）
· 范围：逻辑错误、安全漏洞、严重违反架构规范。
· 话术：“我运行测试时发现，在XX边界条件下，这个判断逻辑会走到一个未处理的异常分支。我们一起看看是不是这个条件判断需要调整？”
“为了确保数据一致性，这个更新操作是不是需要加个事务包裹？我有点担心在异常情况下会出现脏数据。”
星轨金句
一次成功的代码评审，结束后对方的感觉不应是“我被指出了很多错误”，而应是“我和同事一起打造了一段更坚固的代码”。
你的角色不是法官，而是这段代码未来的共同承担者。
▶️下期预告
职场隐形说明书：破译岗位背后的真实晋升密码
📮声明图文
原创@星轨XS出品，未经授权禁止搬运，侵权必究
