老话说得好，“授人以鱼不如授人以渔”。但在实际的代码评审中，面对新人提交的代码，很多时候我们都会陷入纠结：是直接把他的代码改成“完美版本”，还是只抛出问题让他们自己去寻找答案？这种平衡确实像走钢丝，既要保证项目质量，又不能打击新人的积极性。作为过来人，“码农老王”我来分享一下我的经验。
核心思想：灵活平衡，以成长为核心
我的经验是，没有一劳永逸的标准答案，而是要灵活地根据具体情况和新人的特点来平衡。 最终目标是让新人快速成长，成为能够独立思考和解决问题的工程师。
什么时候可以“手把手改”？
这听起来有点像“替他写代码”，但在某些特定场景下，直接修改会更高效，甚至必要：
- 紧急且关键的Bug/安全漏洞： 项目有紧急发布需求，或者代码中存在严重的Bug（比如可能导致数据丢失、系统崩溃）或安全漏洞。这时候时间宝贵，质量是第一位的，直接修正并简单解释是效率最高的做法。
- 新手完全没头绪，反复修改无效： 如果新人对某个问题完全没有概念，或者在你的指导下尝试了几次仍然无法解决，继续让他“摸索”只会浪费时间和挫败感。这时候不如直接给出一个高质量的解决方案，并耐心讲解背后的原理和思路。
- 少量且非常规的、低学习价值的问题： 有些问题可能是一些非常规的语法错误、配置错误，或者是一些只存在于特定环境下的“坑”，新人在短时间内很难通过常规思考解决，且学习价值不高。这时直接修正，并简要说明原因，可以节省双方时间。
- 代码规范的“硬性要求”： 对于团队内部严格的代码规范（比如缩进、命名、注释格式等），特别是那些可以通过IDE自动格式化的，直接修正并告知新人今后注意，或推荐使用自动化工具。
什么时候应该“指出问题让新人自查”？
这才是“授人以渔”的精髓所在，也是我更推崇的做法。
- 可优化但非致命的性能问题： 比如SQL查询可以优化、循环效率不高、算法选择不当等。这些问题通常不直接导致系统崩溃，但影响性能。指出问题，引导新人思考“为什么会慢？”、“有没有更好的方法？”，让他自己去研究不同的数据结构、算法或数据库优化技巧。
- 设计模式、架构理念的不足： 新人代码可能存在重复逻辑、耦合度高、缺乏扩展性等问题。这些是提升抽象能力的关键点。指出“这里是不是可以考虑抽象一下？”、“这个模块以后怎么扩展？”引导他们思考设计原则和模式。
- 可读性、可维护性问题： 变量命名不清晰、函数职责不明确、缺乏必要的注释等。这些问题虽然不影响功能，但影响团队协作。指出“这个变量名如果换一个，是不是更容易理解？”、“这个函数做了几件事？”，让他们从团队协作的角度审视代码。
- 业务逻辑理解偏差： 新人对需求理解有误，导致代码实现与预期不符。指出“根据需求，这个分支逻辑是不是漏考虑了某种情况？”引导他们重新梳理业务流程。
通用原则和心得
- 区分重要性： 对于核心逻辑错误、严重性能问题等，建议更早、更明确地指出；对于编码风格、次要优化等，可以放手让新人探索。
- 沟通是关键： 无论是哪种方式，都要有详细的解释。如果是你直接修改，要说明修改的原因和思路；如果是让他们自查，要给出具体的方向和思考的切入点，而不是一句“这里不对，你去改”。
- 设定期望： 一开始可以允许新人犯一些错误，但要逐步提高要求。告诉他们团队对代码质量的期望是什么，帮助他们建立正确的编程习惯。
- 多用问题引导： “你觉得这段代码有没有可能出现XXX问题？”“如果需求变成YYY，你的代码需要改动哪里？”这样的提问式引导，比直接给答案更有助于思考。
- 及时反馈： 不管是好是坏，都要及时反馈。好的地方要表扬，不足的地方要指出并提供改进建议。
- 耐心和同理心： 我们都是从新手走过来的。理解新人在学习过程中可能遇到的困惑和挫败感，保持耐心，给予他们足够的时间和支持。
- 利用工具： 善用代码评审工具（如GitLab/GitHub的Comment功能），可以在具体代码行进行讨论，提供代码片段示例，让反馈更精确。
总的来说，指导新人是一个动态平衡的过程。初期可能需要多一些“手把手”，随着新人能力提升，逐步过渡到“指出问题，让他们自查”。这个过程考验的是我们的耐心、经验和沟通技巧。
