𝗢𝗽𝗲𝗻 𝘁𝗵𝗲 𝗣𝗥 𝘆𝗼𝘂𝗿 𝗿𝗲𝘃𝗶𝗲𝘄𝗲𝗿 𝗵𝗮𝘀 𝗻𝗼𝘁 𝗺𝗲𝘁 𝘆𝗲𝘁
I reviewed a large pull request recently. It used AI to help write the code. It changed a module that three other features used. The description was only one sentence. It named the file but not the reason for the change.
I spent fifteen minutes mapping the changes before I could start. I had to find the intent. I had to find the risks. I had to separate the important files from the noise.
I realized I had done this to someone else before.
When you write code, you carry all the context. You know why you split a module. You know what you tried first. You know which parts you feel unsure about.
Most people write descriptions for themselves. They write "Refactored service layer" or "Fixed auth module." These are descriptions for people who already know the context.
A good description is for the person who knows nothing.
A description is not just a summary. It is a test. If you cannot explain your work, your work is not ready.
I now use a six-part structure for every non-trivial PR:
• Intent: Explain why this PR exists and the problem it solves. If you cannot write this, stop. The PR is not ready. • Major changes: List decisions that affect architecture or existing behavior. • Minor changes: List cleanups and renames. Keep them separate from structural changes. • Impact: List the systems this touches. Provide a map of the blast radius. • Evidence: List what you ran and what tests you passed. Show proof that you did the work. • Uncertainties: State what you are unsure about.
When you admit uncertainty, you help the reviewer. They know where to look closely. They do not waste time on parts that are working fine.
If you cannot name your uncertainties, you have not thought deeply enough about your code.
The description is the last step before you decide if a PR should even open.
A reviewer who understands your intent spends time on hard questions. A reviewer who must guess your intent spends time on easy questions. They ask what things are instead of asking if they are right.
Write for the reviewer who has not met your code yet. Write as if you will not be there to answer questions. Write as if you are reading it three days from now with no memory of the work.
If the description holds up, the PR is ready.
提交 PR 吧，你的评审员还没遇到过你呢
你可能花了几个小时，甚至几天时间来完善那段代码。你运行了测试，检查了边缘情况，甚至还反复确认了代码规范 (linting)。但当你把鼠标悬停在“创建 Pull Request”按钮上时，一阵焦虑感袭来。
“如果他们发现了一个根本性的缺陷怎么办？” “如果他们觉得我的方法很业余怎么办？” “如果这个 PR 收到 50 条评论怎么办？”
我们都经历过这种时刻。对被评判的恐惧是真实存在的，而且它可能会让你瘫痪。但这里有一个视角转换，或许会对你有帮助：你的评审员还没遇到过你呢。
代码不代表你
最重要的一点是，要意识到你的代码并不代表你的身份。当评审员留下评论说“这种方法可能会导致内存泄漏”时，他们并不是在说“你是一个糟糕的开发者”。他们是在说“这个特定的实现方式存在潜在问题”。
我们非常容易将两者混为一谈。我们将自我价值与函数的优雅程度和算法的效率挂钩。但在专业的工程环境中，代码是一个通过协作不断进化的、鲜活的实体。
评审员是你的盟友，而不是你的法官
我们经常把代码评审看作一场考试。我们觉得自己正站在老师面前，等待着评分。但在健康的工程文化中，代码评审是一场对话。
评审员的目标不是为了抓你的错，而是为了确保代码库的健壮性并分享知识。他们正通过不同的视角审视代码，通常拥有更多的上下文或不同的经验。
当他们建议进行更改时，他们是在帮助你提升水平。他们为你提供了一个获取知识的捷径，而这些知识如果靠你自己摸索，可能需要几个月的时间。
过度打磨的陷阱
有一个陷阱叫做“完美主义循环”。你不断地重构，不断地微调，试图在任何人看到之前让 PR 变得“完美”。
问题在于：你在浪费时间。更重要的是，你在推迟获取反馈的时间。
你越早提交 PR，就越早能让别人看到你的工作。即使它并不完美，你早期获得的反馈也能防止你长时间走在错误的道路上。一个“进行中” (WIP) 的 PR 也是获取早期架构反馈的一种完全有效的方式。
如何对待评审
- 放下自我 (Ego)： 将每一条评论视为数据，而不是侮辱。
- 提出问题： 如果你不理解某个建议，问问“为什么？”，而不是仅仅盲目地照做。这能将批评转化为学习时刻。
- 心怀感激： 详尽的评审说明你的团队关心工作质量以及你的成长。
结语
所以，深呼吸。别再盯着那个按钮看了。
提交 PR 吧。
你的评审员还没遇到过你呢。他们不知道你的挣扎、你的历程或你的潜力。他们只看到了代码。给他们一个机会去审视它、挑战它，并最终帮助你把它做得更好。
可选的学习社区: https://t.me/GyaanSetuAi