共计 4830 个字符，预计需要花费 13 分钟才能阅读完成。
简介：明天小编作为一个开发者，放下内部的客观因素，仅从一个代码的实现者，一个被评审人的角度去思考如何让评审变得高效而富裕意义。换句话说：如何让评审人爱上我（被评审人）。
家喻户晓，每个有技术谋求的团队，都试图想把 Code Review 做到极致。正所谓——未经扫视的代码，不值一提。为什么 Code Review 如此重要，本篇不再赘述，仅做简略总结：
- 提前发现问题，防患故障于未然
- 疾速进步团队新同学的编程能力
然而幻想很饱满，事实很骨感，团队的评审活跃度和评审品质往往令人堪忧，原因种种，上至技术 TL、下至代码性能的实现者，甚至产品经理（嗯，肯定是业务太重导致没工夫做 Code Review）都能成为做不好 Code Review 的罪魁祸首。明天小编作为一个开发者，放下内部的客观因素，仅从一个代码的实现者，一个被评审人的角度去思考如何让评审变得高效而富裕意义。换句话说：如何让评审人爱上我（被评审人）。
为什么要让评审人爱上我
在以往的文章探讨中，咱们往往更专一于如何晋升评审人的程度，如何找出评审代码的问题，或者如何让被评审人能疾速解决提出的问题。但咱们疏忽了评审人的感触，仿佛评审人就是一个毫无感情的找 BUG 机器。当然，不排除一些自动化扫描的工具（比方：Codeup 的缺点查看、破绽剖析等等），它们的确是 AI 机器人。但除此以外很多时候因为对代码的业务了解、团队的编码格调等问题，还是须要团队的其余成员作为评审者染指其中。对于不走心的搪塞评审咱们撇开不谈，评审者参加一次评审还是挺消耗精力和工夫的，须要工夫去浏览、了解、并指出疑难。因而，咱们应该放下防范，坦然看待评审过程，并对评审人心怀感谢。
如何让评审人爱上我
既然咱们曾经下定决心与评审人来一场苦涩的 Code Review 之旅，怎样才能让评审人爱上我（的评审）？我从一次评审的全周期来剖析，别离为：
- 【评审前】如何做好评审前的筹备；
- 【评审中】如何看待评审中的探讨 / 问题；
- 【评审后】评审后须要做什么。
提交评审前
重点：
- 认真扫视本人的代码
- 做好提交（Commit）
- 保障测试基线
认真扫视本人的代码
在评审中，最禁忌的一点就是犯一些低级谬误，这样不仅会给评审者很差的印象，也会将评审者的工夫节约在一些低级谬误之中。所以，咱们要在提交代码前本人先认真扫视本人的代码。
格局问题
格局问题，常产生在一些初建的团队，大家有不同的开发习惯、编码格调，在单人开发中，并没有什么问题。当这个我的项目波及到多人合作时，就会显得很麻烦。比方上面这个评审，其实是没有理论的改变只是编码格调的格式化。但稀稀拉拉的文件变动，往往会让人心神不宁。
因而在提交前，咱们应依照团队的标准，设置好本人的编辑器格局工具，并在提交前查看是否存在格局上问题，防止这种问题在 Code Review 的时候节约大家的工夫。
拼写错误
拼写错误是属于低级谬误了，目前支流的编辑器都反对拼写查看，只有大家认真对待编辑器高亮的 warning，就能找进去啦。
代码标准扫描
一些十分根底问题，能够通过自动化工具扫描进去。比方针对 java 的开发规约检测，代码平台提供的破绽检测、平安扫描等。在提交当前看到分支上改变的 commit 都是绿色的 pass，情绪也会好很多。毕竟咱给评审者提供的代码也是通过一遍初选的复赛选手了。
做好提交（Commit）
说到提交（commit），很多同学都感觉没什么。不就是 git commit 么。或者 commit 的时候，因为 Git 的强制要求必须蕴含 message，才轻易输几个只有本人懂的提交阐明，而后git push 拉倒。比方上面这种提交阐明，我在很多兄弟团队的代码仓库都有见过。
这种提交阐明的问题，我就不再赘述了。接过老我的项目、给老工程填过坑的人都懂。因而在评审阶段，咱们就要做好提交。
- 要点一：按性能拆分提交，回绝大 Diff 评审
在平时的开发中，大家往往都是多个工作并行开发。很多同学又不喜爱来回切换变更的分支，导致很多评审都是多个性能一股脑的提交，因而评审天然也就变得很大。或者在开发一个比拟大的需要时，没能将性能进行拆分细化，导致所有的改变都在同一个评审中，甚至在同一个 Code Review 中。例如：
这个评审，两头混淆了数十个性能的提交，评审者很容易迷失在不同性能的逻辑迷宫中。更有甚者，会提交增删行数高达上万行的评审。对于这种超大评审，我不太置信评审者会认认真真地看完。有钻研自媒体分享的统计，现代人的注意力只能聚焦 5 分钟，如果一个分享超过 5 分钟无奈完结，人们往往会因为想不起来后面的内容而放弃。评审也是如此，长达数万行的改变，都在同一个评审中，即使是在评审页面上提供铆钉已浏览的文件的性能，也很难在短时间内容了解上下文的逻辑。因而评审者须要消耗长达半个小时以上的独立工夫来浏览评审的改变，而这对于失常的开发人员是十分解体的。因而，咱们在实现一个性能的时候，该当正当的按性能拆分，将提交变小（small is beaut iful）。当改变过于宏大应该思考拆分多个评审进行。
- 要点二：形容分明本次提交的内容、改变点、改变影响
一个评审的开始，从关上页面到评审开始，个别眼睛的程序是：评审题目 -> 评审形容 -> 改变列表 -> 改变详情
评审的题目和评审的形容往往就是咱们提交的内容生成的。而作为评审开始的前两个关键点，评审提交形容是十分重要的。比方上面这种例子：
我置信各位作为评审人，看完这个评审曾经想关掉评审了（一些火暴老哥甚至间接点回绝）。令人费解的评审题目，空白的评审形容。即使咱们拿着 Code Review 坐在评审者的电脑前、或者钉钉上附上评审解释，这种体验都是十分不好的，因为大家都不违心注意力被扩散。就像咱们写代码一样，大家都更违心在开发过程中聚焦在编辑器上，而不是在不同的屏幕间来回切换（查看需要、被人中途打搅等）。因而咱们应该写好形容，尽量让评审开始的时候，大家都能在一块屏幕（一个页面上）实现评审的所有工作。
除此之外，良好提交阐明，能够提前让评审者感知到改变点和改变影响。比方上面：
评审者从形容中就能确定咱们改变的中央和改变的影响，从而可让评审者更快的进入状态，而不须要本人去浏览具体内容猜咱们改了什么。
- 要点三：性能改变和非性能改变尽量离开
在一次性能中，咱们除了功能性的改变，可能还蕴含一些非功能性的变动，如果都揉和在一起，往往看起来十分的好受。比方上面这种状况：
在这个改变中，我除了做一些性能上改变，还顺便批改了文档、对以往的格局问题做了格式化。尽管都是同一个改变，但观感还是十分差的。就像老师讲课，好的老师肯定是按内容演绎，按内容传授，而不是代数几何混在一起讲。
因而咱们能够在评审的提交中做进一步的拆分。还是针对下面的例子。咱们调整后的样子为：
在评审页面的左侧点击全副提交，通过提交信息抉择咱们须要独立评审的提交内容。
抉择功能性改变的提交，进行性能改变的评审。
抉择非功能性提交，便能够只关注非性能的改变。比方这里咱们只用独自看下 README 里的改变就能够，全程清新。
保障测试基线
在很多曾经成型的我的项目中，往往都有充沛的测试笼罩扫描。当咱们提交代码的时候，在性能上咱们第一个要保障的就是以往的测试都能通过（除非是这个测试用例曾经废除或存在谬误，这种咱们应该单拎一个性能来修改），这也是对评审者的尊重，因为连性能的正确性都无奈保障的评审是无意义的。
在云效中，咱们能够将评审的指标分支作为爱护分支，在自动化查看中配置自动化查看。通过在流水线中通过灵便的配置来设置咱们工程中须要卡点查看。
而后，在咱们提交的评审的时候，就会主动触发咱们配置的卡点了。如果卡点不通过，是不容许评审通过的。因而咱们在提交评审中，要留神卡点的内容，要让咱们的评审“绿”起来。
评审中
重点：
- 踊跃看待评审反馈
- 代码是最好的解释
- 原谅评审人的误会 / 失误
- 保障 Code Review 的时效性
踊跃看待评审反馈
一部分同学恶感代码评审的起因是，他们认为评审人是无意尴尬本人。不能排除在一些比较复杂的社会环境中的确可能存在这种问题。然而作为被评审人，咱们还是要踊跃的对待评审的反馈。毕竟鸡蛋里挑骨头的前提是要有骨头，问题提出就肯定有其合理性。绝大部分技术人看待代码还是中立的，不能踊跃面对评审更多的是咱们放心本人的代码不够好，怕他人指出问题。但换个角度想，评审人其实也是在帮忙咱们，早点在评审阶段发现问题，总比线上出了问题要好。另外，在一直的评审中，咱们也能疾速的提高本人的编码能力。
代码是最好的解释
当评审者对咱们的代码提出疑难的时候，咱们除了解释，更应该做的是思考为什么会呈现这种疑难。有时候尽管我对评审人的疑难做了具体的回复，评审人仿佛也了解了。但这个评审真的就完结了吗？马克思老人家说，咱们应该透过景象看实质。毕竟评审人可能不只一个，即使以后的其余评审人看到这个解释也能明确, 但咱们无奈保障后续波及这块的代码改变再次评审的时候，会有人能明确这里的歧义。因而这种存在歧义的评审质疑，其自身的问题是代码未能做很好的解释。
面对这种状况，个别的倡议增加充沛的代码正文。但我更倡议咱们间接对代码进行重构，让代码自身就能解释分明其意义。
原谅评审人的误会 / 失误
孔子云：人非圣贤孰能无过。评审者在评审中也会存在对正确代码的误会。在这种时候，咱们不能得理不饶人，该当放弃谦虚。正如在开篇中提到的，评审者理论是对咱们提供帮忙的，帮毁灭咱们本人未知的隐患。因而咱们不应该贸然出击，该当感性回应，在解释的同时也是对咱们本人的代码的一个很好的回顾。除此之外，咱们还应意识到这里另一个问题—— 存在即正当，如果评审者提出了疑难，是否证实这里存在不合理性，可能是代码有歧义须要重构？
保障 Code Review 的时效性
评审也应该有时效性。因为评审人评审的代码，往往不是本人的参加的业务，评审周期拉的太长，可能会想不起来。因而在评审中，往往会设置一个揭示的钩子。配合钉钉的 webhook 接管，能尽早的感知评审的人的意见。
在批改完结后及时给予反馈。这样让评审者对评审还没“冷却”的时候，就能更快的持续评审，大家就能早早上班啦。
评审后
评审后，评审的内容会保留在平台上，前面能够随时查看回顾。除此之外，在评审后最重要的是抉择一个合并形式。个别我会抉择 squash 的模式进行合并。将评审中的所有提交合并为一个 commit。这样合并到骨干中，一个提交就是一个性能。留神，这个和前文的提交拆分并不是一回事。在提交评审阶段，咱们为了不便评审，将提交拆为性能改变和非性能改变。但在合并阶段因为曾经通过了评审。咱们要将一个性能的改变放到一个提交中。
点击合并后，评审中的屡次提交最终会压缩为一个 commit 合并到指标分支中。这样也就保障了一个性能一个 commit 的准则。在后续排查问题和线上回滚都会十分不便。
P.S. 合并形式应该根据各自团队对工程治理和开发模式的抉择来决定，以上只是一个简略的例子。
总结
总结一下，如果让评审者爱上给我做评审，我会这么做：
- 提交前认真扫视本人的代码，回绝低级谬误
- 按性能拆分提交，写好提交阐明
- 让所有的单侧、集测变绿通过，保证质量基线
- 踊跃看待评审反馈
- 用代码解释评审者的疑难
- 正确对待评审者的误会 / 失误
- 及时修改 / 反馈，保障评审的时效性
- 评审后抉择正确的合并形式
本文作者：陈博俊，阿里云技术专家，Git 开源我的项目贡献者，负责阿里巴巴经济体代码平台及云效代码平台底层架构设计及运维开发。
长按辨认上图二维码 立刻报名
6 大专场
27 位海内外技术大咖
邀你共享效力盛宴
锁定 6 月 23 日 - 6 月 24 日
9:00-12:00 14:00-18:00
咱们期待与您共建研发效力美好未来！
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
