面试官问“你怎样带新人、怎样做代码评审”，应该怎样回答？

本题是回答思路与示例，不对应某个官方规范。示例中的数字只用来演示怎样表达，讲自己的项目时请用真实数据。

简答

这道题一般出现在中高级岗位，面试官想知道你除了自己写代码，能不能帮别人成长、能不能守住团队的代码质量。所以要讲具体做法和例子，不要只说“我会耐心指导”。

带新人我会分几个阶段。入职前准备好能一条命令跑起来的开发环境和一份上手文档；第一周给一个范围小、能完整走完开发、评审、发布流程的任务，让他熟悉流程；之后任务逐步加大，到能独立负责一个模块。过程中定期一对一，问他卡在哪里，评审他的代码时多解释为什么，而不是直接给答案。

代码评审我先看大的：方案对不对、有没有 bug 和边界情况、有没有测试，然后才看命名和可读性。我认同 Google 工程实践里的标准：只要这次改动明显让代码变好了，就可以批准，不必等它完美。只是建议的小问题，我会标成“Nit”，作者可以不改。评论针对代码，不针对人，并且说明理由。

要注意两点。一是改动要小，Google 的指南建议一次改动只做一件事，太大的改动评审者很难看仔细。二是格式这类问题交给工具自动检查，评审时间留给机器查不出的问题。

一个带新人的示例

背景：去年组里来了一位应届同学，之前只写过课程项目，没接触过公司的组件库和发布流程。

做法：入职当天我先带他把项目跑起来，碰到文档里没写的步骤就当场补进上手文档。第一周给他一个修改表单校验提示的小需求，目的是让他完整走一遍拉分支、提交、评审、发布的流程。之后每周给他一个稍大的需求，从改已有页面到独立开发新页面。每周固定半小时一对一，问他遇到的困难，也听他对流程的意见。他的代码评审我会写得比平时详细，比如为什么这里要处理请求取消，并附上相关文档链接。

结果：大约两个月后，他能独立负责一个模块的需求，后来还按自己踩过的坑补充了上手文档。下一位新人入职时，从拉代码到跑起来的时间明显缩短了。

为什么这样讲？它说明了你有方法：任务由小到大、有固定的沟通机制、把经验沉淀成文档。最后的结果也不只是“他成长了”，还有对团队的改进。

代码评审看什么、怎样写评论

评审的顺序是从大到小。先看方案是否合理，这个改动是否应该这样做；再看正确性，边界情况、错误处理、并发和竞态；然后看有没有测试覆盖关键逻辑；最后才是命名、注释和代码组织。为什么要先看大的？因为方案有问题，细节改得再好也要重来。

批准的标准是什么？Google 的评审指南说，只要改动明显改善了代码的整体健康度，评审者就应该倾向于批准，即使它不完美，因为没有完美的代码，只有更好的代码。这能避免评审拖很久、作者反复修改小细节。

评论的写法也重要。只是建议的小问题，前面加上“Nit:”，表明作者可以不改；纯粹教学性质的评论，也说明不要求这次修改。要求修改的问题，讲清楚原因，最好给出建议的写法。评论对事不对人，说“这里在请求失败时没有恢复按钮状态”，而不是“你又忘了处理错误”。

怎样让评审更高效

改动要小。Google 的指南列了小改动的好处：评审更快、更仔细，引入的 bug 更少，方向错了浪费的工作也少。它给的参考是一次改动 100 行左右通常合适，1000 行通常太大，但主要看是不是只做一件事。所以我会建议把重构和功能需求分开提交。

机器能检查的不要靠人。格式、lint、类型检查和测试放进提交检查和 CI，评审者看到的代码已经通过了这些检查，评审时就能专注于逻辑和设计。代码规范怎样落地见《面试官问“你在项目中做过哪些工程化或规范建设”，应该怎样回答？》。

明确谁来评审。GitHub 的 CODEOWNERS 文件可以给目录指定负责人，有人改了这些目录，合并请求会自动请负责人评审，不会出现谁都以为别人会看的情况。

常见追问

评审时和作者意见不一致怎么办？

先确认分歧在哪里，是事实问题还是偏好问题。如果是正确性问题，比如会产生 bug，就用例子或测试说明，坚持要改。如果是风格偏好，团队没有规定的，就尊重作者的写法，或者把它拿到团队里讨论，定成规范，而不是在一个合并请求里来回争论。实在定不下来，可以当面或语音沟通，比文字评论快得多。

新人的代码问题很多，全部指出来会不会打击他？

我会分清主次。影响正确性的问题一定要改，风格上的小问题挑几个有代表性的讲清楚道理，其余的标成可选，或者在一对一时统一讲。看到写得好的地方也会说出来。目的是让他下次自己能避开这些问题，而不是一次把所有问题都改完。