设计方案表网站名称,做网站是通过怎么挣钱,wordpress 二维码 插件,logo免费设计网站简介#xff1a; 今天小编作为一个开发者#xff0c;放下外部的客观因素#xff0c;仅从一个代码的实现者#xff0c;一个被评审人的角度去思考如何让评审变得高效而富有意义。换句话说#xff1a;如何让评审人爱上我#xff08;被评审人#xff09;。
众所周知#x…简介 今天小编作为一个开发者放下外部的客观因素仅从一个代码的实现者一个被评审人的角度去思考如何让评审变得高效而富有意义。换句话说如何让评审人爱上我被评审人。
众所周知每个有技术追求的团队都试图想把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开源项目贡献者负责阿里巴巴经济体代码平台及云效代码平台底层架构设计及运维开发。
原文链接
本文为阿里云原创内容未经允许不得转载。
