代码评审与团队沟通：让别人看懂这次改动
你发来一千行修改，只写“完成收藏功能”。同事不知道从哪里看，也不知道哪些行为是故意改变的。代码评审不是找一个人替你通读全部项目，而是共同检查这次变化是否解决了问题、是否引入了新的风险。
1. 先把改动缩小到一个目的
一份修改同时包含收藏、主题换色和目录重命名，评审者很难判断哪里与需求有关。尽量按独立目的拆分，让每份改动能单独解释和验证。不过不要为了追求行数小，把一个必须一起工作的接口和调用方拆成无法运行的状态。
小改动的优势是上下文少、反馈快、出现问题时容易定位。它不等于固定要求每份提交少于多少行，数据库迁移或生成文件可能有不同情况。
2. 写清楚问题、行为和验证
拉取请求常缩写为 PR，它是托管平台上讨论并合并分支改动的载体，不是 Git 本身的一条命令。描述可以写成下面这样：
问题：重复点击收藏会出现重复记录。
变化：同一用户和文章只保留一条；重复请求返回已保存。
验证：正常保存、顺序重复、并发重复、跨账号访问均已检查。
限制：本次没有增加共享收藏夹。
附上需求编号或讨论链接，评审者就能知道“正确”意味着什么。截图能帮助检查界面，但不能代替数据约束和权限测试。测试结果也要注明在哪个环境、以什么命令运行。
3. 按风险阅读，而不是只挑格式
先看设计是否符合需求，再看正确性、权限、失败处理和测试，最后看命名与表达。格式最好由工具统一处理，让人的注意力放在需要判断的地方。
例如看到代码从请求体直接读取 userId，就要问服务端是否验证了这个身份。即使按钮只能在登录后看到，用户仍可能自己构造请求。再看重复保存的实现是否只做了“先查询再插入”，这可能在并发时失效。
这种阅读需要对照上下文，不能仅凭一行看起来熟悉就下结论。必要时运行测试或请作者补充例子，区分“这里有确切错误”和“我还没理解这个选择”。
4. 给出可以采取行动的意见
“写得不好”无法指导修改。可以改为：“两个同时到达的请求都可能通过不存在检查，请用唯一约束守住同一用户与文章的规则，并增加并发重复用例。”这条意见包含条件、后果和下一步。
建议明确区分必须修复、可选建议与求解释的问题。对于只是个人偏好的命名，不应包装成严重缺陷。作者也不必机械接受所有建议，可以说明约束、展示证据，并共同决定取舍。
5. 评审结束后还要做什么
改完意见后再次运行受影响的检查，并让评审者看到最终版本。合并之前确认讨论已经处理、自动检查通过、没有混入调试输出或秘密。合并之后还要确认发布结果，代码进入主分支并不意味着网站已经更新。
一个人维护项目时也可以采用同样方式：暂时离开实现细节，再从用户场景重新读差异。它不能替代另一位熟悉系统的评审者，却比“我刚写完所以肯定懂”多一层检查。
6. 把重要讨论沉淀到能找到的地方
聊天适合快速对齐，但关键规则只存在聊天里会很难追踪。把最后决定写回需求、接口说明或 ADR，并在改动说明中链接。无需记录每句对话，只保留以后会影响判断的结论与理由。
练习与参考答案
把“这里用设计模式更优雅”改成有帮助的意见。参考答案：“当前保存逻辑在三个页面重复，修改规则容易漏掉一处；建议提取共用收藏用例，保留每个页面自己的显示方式。”先说明具体维护问题，再讨论工具或模式，沟通会清楚得多。