新手如何从代码Review中学习

本文目录导读：

1. 第一阶段：改变心态，从“防御”到“好奇”
2. 第二阶段：Review 之前——先做好“自审”
3. 第三阶段：Review 进行时——分类学习
4. 第四阶段：成为更好的 Reviewer——反向学习
5. 第五阶段：建立你的“代码 Review 个人错题本”
6. 核心原则

对于新手来说，代码 Review（CR）确实是成长最快、也是最容易被忽视的学习渠道，很多新手会把 CR 当成“被审判”，但其实它是免费的、一对一的、由资深工程师提供的定制化指导。

下面是一份从新手视角出发的、可操作的代码 Review 学习指南。

第一阶段：改变心态，从“防御”到“好奇”

这是最重要的一步，当你看到几十条评论时，本能反应可能是：“我好差劲”或“他是不是在针对我？”。

正确的态度应该是：

• 把 CR 当成宝藏： 每一个 Comment 都是别人花时间帮你发现的盲区，感谢评论者,而不是感到被冒犯。
• 你不是你的代码： 评论是针对代码的，不是针对你个人的，资深工程师指出问题，是因为他们希望你变强,而不是想看你出丑。
• 承认无知是进步的起点： 大胆地说“这个我不太懂，能解释一下为什么这么做更好吗？”

第二阶段：Review 之前——先做好“自审”

在你把代码交给别人 Review 之前，先自己扮演一遍 Reviewer，这不仅能减少对方的负担,也是你自我学习的过程。

自审清单（新手版）：

1. 功能正确吗？ 有没有明显的逻辑漏洞？边界情况（如空值、0、负数、超大数）处理了吗？
2. 命名清晰吗？ 如果自己都解释不清变量名,别人肯定也看不懂。
3. 有重复代码吗？ 看到 Ctrl+C/V,问问自己能不能抽成一个函数。
4. 能再简单点吗？ 有没有写了“聪明但难懂”的代码？尽量保持简单。
5. 有调试代码吗？ （如 console.log、println）检查并删掉。

学习点： 这个过程能训练你自己发现问题的能力,这对未来写高质量代码至关重要。

第三阶段：Review 进行时——分类学习

当别人给你提 Comment 时，可以按以下分类来学习,这样不会觉得杂乱无章。

业务逻辑 Bug：最核心的学习

• 例子： “这个 if 条件遗漏了用户已注销的情况，会导致空指针异常。”
• 学习： 这种 Bug 反映了你对业务场景理解不够深。做法： 立刻记录这个场景，补充到自己的测试用例里，以后写类似逻辑时,会自然想到这个坑。

代码规范与风格：最应养成的习惯

• 例子： “这里要用 4 空格缩进”、“变量名用驼峰”、“函数超过 50 行了，拆一下”。
• 学习： 团队为什么要这么规定？函数要短”，是为了可读性和可测试性。做法： 花 30 分钟仔细阅读团队的 Coding Style Guide（编码规范），并配置好 IDE 的自动格式化工具（如 Prettier、ESLint、clang-format）。不要在规范上浪费精力，让工具去做。

设计/架构洞见：最有价值的提升

• 例子：
  • “这个逻辑放到 Controller 不合适，应该放到 Service 层。”
  • “用继承不如用组合，这里用策略模式会更灵活。”
  • “每次请求都查一次数据库太慢，建议加个缓存。”
• 学习： 这是从“能写”到“会写”的飞跃。做法：
  • 追问 Why： 不要只改，要问“为什么 Controller 不该放逻辑？为什么组合优于继承？” 这会引导你去学习设计原则（SOLID、DRY 等）。
  • 看相关代码： Reviewer 可能提到了一个设计模式，去代码库里找找这个模式的其他实现,对比一下。
  • 查阅资料： 利用这个 Comment 作为起点，去学习你知识树上的新节点（缓存策略”、“DDD（领域驱动设计）分层”）。

性能与安全：进阶的素养

• 例子： “这个循环里每次都用 拼接字符串，建议用 StringBuilder”、“用户输入没有转义，有 SQL 注入风险。”
• 学习： 这种 Comment 通常来自有经验的工程师。做法： 记下来，然后去搜索引擎搜索“为什么 String 在循环中性能差”或“SQL 注入原理”,这会让你写出更健壮的代码。

第四阶段：成为更好的 Reviewer——反向学习

想真正学好，最好的方式是去 Review 别人的代码,哪怕你只是初级水平。

• 看别人的代码： 看同事的 PR（Pull Request）是了解整个系统和最佳实践最直接的方式。
• 如何开始 Review 别人：
  1. 先从简单的看起： 注释拼写错误、不规范的命名、缺少的单元测试。
  2. 带着问题看： “这段代码我读懂了吗？” 如果读不懂，说明可能代码可读性差，你可以 Comment：“这段逻辑我不太理解，能加点注释或拆一下吗？”
  3. 遇到不懂的，私下问： 看到别人用的你不懂的技术（如 Stream API、某个设计模式），可以直接问：“我看到你这里用了 <某种技术>，能简单讲讲为什么吗？”
• 学习点： Review 别人的代码，等于看了一个真实的“代码案例”，能看到别人怎么思考、怎么解决复杂问题,这是模仿学习的最佳场景。

第五阶段：建立你的“代码 Review 个人错题本”

不要只靠脑子记,建议用文档或笔记软件记录。

错题本模板：

# 代码 Review 学习记录
## 2023-10-27 - 用户注册模块 PR
-   **问题：** 忘记对 `email` 字段进行唯一性校验。
-   **原因：** 只关注了前端校验，忽略了后端。
-   **改进措施：** 以后所有唯一性字段，后端都必须加数据库约束和代码校验。
-   **标签：** #后端安全 #数据校验
## 2023-10-28 - 报表查询 PR
-   **问题：** 在 `for` 循环里执行 SQL 查询（N+1 问题）。
-   **原因：** 不知道 ORM 框架（MyBatis/JPA 等）有批量查询功能。
-   **改进措施：** 学习 ORM 官方的批量操作文档，并重写。
-   **标签：** #性能优化 #数据库

定期回顾： 每周花 15 分钟翻看你的错题本，你会发现，很多错误模式（如 N+1 查询、忘记处理错误、边界条件遗漏）会在不同项目里反复出现，一旦你开始模式识别,就说明你真的进步了。

核心原则

1. 不要怕犯错： 代码里犯错是必然的，CR 的存在就是容错和纠错的。
2. 追问到底： 不要只满足于“改完”，问清楚 Why,才是学到精髓。
3. 模仿比原创更高效： 看到好的写法，Reviewer 给出一段优雅的流式处理，直接复制下来，下次遇到类似场景“照着写”,这是最有效的学习。
4. 把 CR 看作长期投资： 初期会觉得慢，但一个月后，你会发现自己的代码 Bug 变少了，被 Review 的轮次变少了,甚至开始能给别人提有价值的建议了。

最后送你一句话： 你在代码 Review 中看到的每一个 “应该这样” ，都曾是那个资深工程师自己踩过的坑，今天你看到的,就是你明天要避开的。