关注【索引目录】服务号，更多精彩内容等你来探索！
我们来聊聊代码审查中究竟发生了什么。
你认识那个刚辞职的初级员工吗？就是那个在离职面谈里提到你的评价让他觉得自己永远都不够好的？没错，我的团队里就发生过这种事。在你觉得“我的初级员工都很喜欢我的反馈”之前，先问问自己：如果他们不喜欢，他们会告诉你吗？
这并非指责谁。好吧，其实——的确如此。因为太多资深开发者把代码审查变成了一场表演，我们是时候该指出来了。我自己也犯过这样的错误。但这并不意味着我们不应该揭露整个行业正在发生的事情。
🎭 “最佳实践”剧场
模式是这样的：一个初级程序员提交了一个 PR，优雅地解决了问题。测试通过，逻辑也正确。然后你就插话进来：
userData“这个变量不应该是 user”-
我们能让它更实用吗？ -
“我本来会用工厂现成的模板。” -
“嗯，有趣的方法……”（翻译： “这样做不对，但我想要显得深思熟虑”）
与此同时，他们真正错过的 bug 呢？会导致生产环境崩溃的极端情况呢？你没发现它，因为你忙着争论他们的函数应该被调用processData还是调用handleDataProcessing。
你不是在审查他们的代码，你是在运用你的专业技能。
⚔️ 吹毛求疵的权力之旅
让我们坦诚地谈谈代码审查对许多资深程序员来说已经变成的什么：一种武器。也许并非出于恶意，但其影响却是一样的。
完美主义者的游乐场
每一次 PR 都变成了展示你如何做得更好的机会，而不是展示如何改进他们的代码。
你偷偷塞进一些你刚学到的晦涩难懂的模式。你把之前公司的架构决策当作普遍真理来引用。你留下的评论其实只是你的自言自语，而不是什么切实可行的反馈。
移动球门柱游戏
-
🥇第一轮： “使用更具描述性的名称” -
🥈第二轮： “其实，这些名字太冗长了” -
🥉第三轮： “你能重写整个函数吗？” -
💀第四轮：他们放弃了，正在更新简历
听起来是不是很耳熟？如果你这样做，你不是在“维护标准”，而是在欺凌新员工。
冷战
三天了。没有评论。没有批准。只有……沉默。
你告诉自己“太忙了”或者“需要再想想”。但实际上呢？你只是在拖延给出有效反馈这项艰巨的任务。而你的沉默呢？它赋予你权力。它让你成为瓶颈。它让别人等着你。
那不是领导力，那是把关。
🚨 你忽略的真正问题
当你在争论语法糖的时候，你却没问到这个问题：
-
这样真的能解决用户的问题吗？ -
我们是否在引入技术债务？ -
这真的是应该开发的功能吗？ -
这种模式可以推广吗？ -
有人测试过正常流程之外的情况吗？
当然，你可以争论这应该是一个类还是一个函数。因为这些争论会让你觉得自己很聪明。而那些真正需要思考的问题呢？
🤷♂️“但是代码质量！”
是啊，大家都用“代码质量”来解释。
但你实际创造的是：
- 初级开发人员学会编写能通过你审查的代码，而不是编写优秀的代码。
- 一个团队，真正的学习不再发生。
- 在一个因你基于偏好的吹毛求疵而扼杀创新的环境中
你并没有提高标准，只是为了保持竞争力而不断调整标准。
🧪 自我测试
当出现以下情况时，你的评价文化就是有害的：
-
你因为一些不符合任何风格指南的风格偏好而屏蔽了 PR——这些偏好仅仅是你的个人偏好而已。 -
你的评论只关注他们是如何做的，而没有关注这种方法是否有效。 -
你对其他资深人士的糟糕做法表示认可，却对低年级学生犯同样的错误大加挞伐。 -
讨论帖的长度往往超过了差异本身——因为你无法放手。 -
你会发现自己心里想着：“如果我找不到什么问题，人们就会质疑他们为什么需要我。”
如果你发现自己符合以上任何一点，恭喜你：你也是问题的一部分。
✅ 代码审查的真正意义是什么
代码审查应该：
-
发现漏洞和安全问题（你知道，就是那些重要的事情） -
分享为什么某些方法更好，而不仅仅是断言它们更好。 -
验证解决方案是否符合问题要求。 -
确保测试真正检验的是重要内容。 -
要进行对话，而不是单向讲授
注意到缺少了什么吗？
证明你比作者更聪明。
🌱 一篇好评论到底是什么样的
大多数老年人写道：
“这种方法无法扩展。请使用仓库模式重写。”
导师制的具体形式：
“不错的解决方案！不过有个问题：这种方法会循环查询数据库，如果记录很多，速度可能会比较慢。你能不能批量处理一下？如果需要的话，我很乐意一起研究——这是我们之前用过的方法：[链接]。但如果这种方法有什么我没考虑到的原因，请告诉我！”
第一种是把关，第二种是合作。
你在做哪一个？
🌑 令人不安的真相
大多数评论都带有表演性质。
它们不过是披着质量控制外衣的掩盖真相之举。它们其实是你为了维护自己“资深”的地位而采取的手段，因为你觉得自己比谁都懂。它们其实是你害怕如果没发现问题，别人就会质疑你存在的意义。
是的，我也犯过同样的错误。但认识到问题的存在并不能免除我们解决问题的责任。
🤔 在点击“提交”之前需要问自己的问题
在你留下下一条评论之前，请强迫自己回答以下问题：
-
我进行代码审查是为了改进代码，还是为了炫耀？ -
这条评论是有用的还是只是批评？ -
我是因为个人偏好还是实际问题而选择屏蔽？ -
如果这段代码是另一位资深人士写的，我会接受吗？ -
这条评论会帮助他们成长，还是只会让他们感到渺小？
如果你对自己诚实，你可能会删除一半的评论。
🧾 底线
良好的代码审查：
-
捕捉昆虫 -
传播知识 -
改进系统 -
增强自信心
糟糕的代码审查：
-
迷雾笼罩着人们 -
拖慢球队速度 -
维护自尊心 -
吓跑人才
有时，你能给出的最好评价是：
“看起来不错，发货了。”
当你收到反馈时，先说说哪些方面做得好，再指出哪些需要改进。多问问题，少妄下断言。要像对待专业人士一样对待每一位公关稿撰写者。
挑战来了：去看看你最近的 10 次代码审查。认真仔细地看看。你的评论有多少是关于实际问题的，又有多少是关于个人偏好的？你问了多少问题，又提了多少要求？如果你把精力放在真正重要的事情上，有多少 PR 可以提前一天发布？
资深开发人员/评审员的职责不是当守门人，而是打开大门；是鼓励他人，而不是打击他人；是运用我们的经验让团队变得更好，而不是证明我们是房间里最聪明的人。
问题是：你这样做了吗？
还是说你只是在搞一场自我膨胀的竞赛，却美其名曰“代码审查”？
关注【索引目录】服务号，更多精彩内容等你来探索！