请勿在拉取请求中留言，请留下图片。

模因行动

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

一图胜千言，对吧？每当你审查拉取请求（或在任何其他情况下审查代码）时，你可能会发现自己在写大量的笔记，进行临时对话，甚至做一些类似“社交媒体”的事情——比如+1给某个东西点赞，或者在上面贴满表情符号。

但我这周突然顿悟：我为什么要花这么多时间敲代码说明、解释应用程序流程、提出替代方案呢？事实上，我那张帅气的脸蛋很多时候就能完美地传达我对某个 PR 的所有想法。所以，为什么不直接放上合适的图片……然后就完事了呢？

我知道。你可能对这个想法持怀疑态度。你甚至可能觉得我终于到了该另谋出路、放下键盘、告别 Dev.to 的地步了。但你之所以这么想，只是因为你还没看到我即将提交的那些 PR 图片。

仔细观察……你会感到惊叹！

铅笔鞭策式的认可

有没有遇到过这种情况：有人让你“审核”他们的 PR，但很快你就发现他们根本不是想让你审核，只是想让你签字批准？事实上，如果你开始添加评论，他们甚至可能会有点不耐烦。他们不需要你的意见，他们只想有人签字批准，好让他们把 PR 合并。在这种情况下，我会把这张图贴到 PR 上。

注意：我没说我会批准。我只是把这张图放上去。等他们回来问我为什么还没批准，我就问他们：“老兄，你没看到我竖起的大拇指吗？？？”

你没你想象的那么隐蔽。

你有没有见过那种开发者试图“蒙混过关”的 PR 代码？它可能违反了公司政策，也可能在性能或安全方面存在问题，甚至可能是故意混淆代码。这张图就是在告诉开发者：我完全看透了他们的意图。

注意：这并不一定意味着我不会批准这个 PR。说实话……我们都会有觉得某些东西必须合并<ahem>的时候——原因可能有很多。有些原因甚至可能有点“正当”。但这张图片清楚地表明，你的努力我都注意到了。只要你知道，我也知道，那就没问题了。</ahem>

好多“不”

听着——我几乎从不拒绝 PR。我几乎总是会在尚未关闭的 PR 上提出建设性的意见，或者和你实时沟通，解决我的一些顾虑，甚至直接忽略PR。所以，如果我真的拒绝了PR，那很可能意味着你在代码里做了（或者正在做）一些让我非常恼火的事情。在这种极其罕见的情况下，简单的拒绝是远远不够的。这张图肯定能更好地表达我的真实感受。

超级不

你有没有遇到过这种情况：你指出了一个 PR 的问题，然后程序员撤回了 PR，之后过了一段时间，他们又用完全相同的代码重新提交了 PR ？我甚至见过他们在我以为我不在办公室没注意的时候重新提交 PR（这种情况，我得找张三个大拇指朝下的图片）。

明显缺乏互相吹捧

我的公关稿已经放在那里一个半星期了。你既没有批准，也没有评论。我甚至提醒过你需要审核，但你仍然置之不理。

但是现在……你有个紧急的公关稿，急切地想让我赶紧批准？？嗯……当然可以。

先生，您真是个聪明绝顶的家伙！

或许你认为我所有的公关回复都是负面的，但事实并非如此。偶尔，你的同事也会提交一些真正精彩的作品。遇到这种情况，仅仅简单地点击一个“批准”按钮就太可惜了。

滚开！

有些事会让我立刻终止代码审查。比如，如果你的新 JavaScript 代码里有 `<script>`var标签——哪怕 var只是一个简单的标签——审查就结束了。我根本不会费心去看剩下的部分。赶紧把这玩意儿从我的屏幕上清除出去。

我只是来评论的

你有没有遇到过这种情况：打开一个 PR，发现上面已经有人开了个长篇大论，感觉像是从 8chan 逃出来的？争论不休，武断的宣言，有人引用“公司政策”（通常是同一个人，他自己for提交代码的时候根本不遵守“公司政策”）。还有人争论循环和……哪个性能更好.forEach()。

我通常不会碰那些个人最佳成绩。一旦战线划定，我唯一的“角色”就是坐享其成。

梵语低语者

这个 PR 里有 1000 行代码，其中一半都是复杂的正则表达式。这位程序员非常喜欢Lambda 表达式，因为它允许他用一行代码写出整个组件。每个变量名都是缩写，例如，`var`getUser()会变成 `var` gtUsr()。

我们以后永远不要再提起这件事了。

你要把那个 PR 删掉。我会假装没看到。我们俩以后都没必要再想起你刚才提交的那堆乱七八糟的东西。这种情况通常只适用于有人提交了一段存在严重安全漏洞的代码。

注意：这张图本身就足以说明一切。我凝视着虚空（你的代码），它也凝视着我。我们都被这种体验震撼了。我只需要把这张图贴到 PR 上就行了。如果这就是我的反应，而你还需要我指出你的代码里哪里引发了这种反应，那么要么你该走了，要么我该另谋出路了。

哦真的吗？？？

你有没有遇到过这样的人：他试图通过提交未来的代码来“赢得”之前你们讨论过的某个争论？比如，他坚信所有字符串比较都应该用正则表达式。于是，在他的下一个 PR 中，他把代码库中所有现有的字符串比较都改成了正则表达式——尽管这和他提交代码的初衷毫无关系。

失败的实验

我完全明白你的意图。说不定在你提交代码之前，我们就已经讨论过这种方法了。而且，在我们讨论的时候，理论上来说，这听起来确实是一个可行的方案。

但是现在……现在我终于看到了实际的实现方式？嗯……不行。实际操作起来非常糟糕。我们得想想更好的办法。

五五开

你看……代码没错，但肯定也不对。我估计不会拒绝这个 PR，但我也不知道我有没有勇气批准它。嗯……这只是个开始，里面有些不错的东西。但是，唉……它还需要好好打磨一下。

理发

这其实不算是个糟糕的提交。真的。里面有些不错的东西。但我非常确定，这个 86 行的函数完全可以用……大概 10 行左右的代码实现同样的功能。

大球手

我会全力以赴地搞定这次公关。但我不会用它做任何对你或其他人有用的事。但我肯定会全力以赴。

我会添加一些评论，这些评论全部由表情符号组成，与评论所在的代码没有任何逻辑关联。我会回复其他评论者在 PR 下的评论。我还会评论一下我最近在研究的一个很棒的新软件包——这和你的提交没有任何关系。

注意：我绝对不会在任何时候批准或拒绝您的 PR，也不会直接引用您提交中的实际代码。

督察

你还记得我上次提交的 PR 吗？我肯定你记得，因为你给了我 37 条修改建议——而那次提交的代码只有 20 行。你对我的命名规范吹毛求疵，建议我改成 `<script>` getUser()，但后来你意识到 ` <script>` 与代码库其他部分一致getMember()，又让我改回去。你让我把箭头函数改成旧式声明，因为你不喜欢箭头语法。你坚持要把状态值放到单独的 reducer 里，放在单独的文件中。你还要求我把 `<script>` 转换成独立的 CSS 类。getUser()userfunctionstyle={{marginTop: 2}}

这张图就是给你的警告。如果你真的想让我继续写这篇评论，我绝对会。事实上，我今天可能除了这篇评论什么都不做。因为我要带着那种幼稚、刻薄、不成熟的复仇心态，逐字逐句地细细品读。

你真棒！

你有没有过这样的经历：在审查别人的代码时，发现他们重写了你最初写过的部分——而且很明显他们做得更好？如果发生这种情况（这种情况很常见），我会把这张图贴到 PR 里。

戏剧化的复仇者

这张图并非针对代码本身的任何特定评论。相反，这是我对那些在审查你的代码时忍不住大惊小怪的人的回应。

你有没有遇到过这样的人：他不仅不能对你的代码提出意见，反而要表现得好像每一个微小的“错误”都是对你人格的巨大打击？

“我的天哪，大家快看！！亚当居然忘了在这行末尾加分号！这菜鸟是谁教他上网的，对吧？？？”

对于这种人，我会把这张图贴到所有需要注释的代码段上。不管意见多么微不足道，我都会把每一条反馈都当成“我见过的最糟糕的代码”来对待。

结论

既然你已经读完了这篇文章，我相信我们都能认同，在代码审查中，传统的注释已经完全过时了。打字反馈简直是……六个月前的老黄历了。只要你拥有足够多的独特表达式，你就再也不用打字了！