主题：如何在团队开展codeReview

背景说明

团队规模在扩大，代码量在不断增长，对代码质量的控制势在必行，codeReview得搞起来，这道理大家都懂，只不过有人重视，有人无所谓，还有人开始的轰轰烈烈，最终却虎头蛇尾、流于形式

这其中自然是有诸多难处，但本质上还是取决于你对codeReview的价值认知，只有大家真切的从codeReview中得到好处了，认识到这个东西真的香，才有可能搞得好，不然你试试？

我们团队一直在搞codeReview，但是效果不太好，属于流于形式的那种(大家都厌倦了)，不然怎么有我上场的机会呢。最近leader要求重新整一套codeReview方案，负责人是我

今天就跟大家谈谈如何制定团队codeReview方案，希望对大家有所帮助

前面说了，必须得大家一致认可cr的价值，才有可能搞得好，所以有必要说下之前我们在codeReview过程中遇到的一个比较大的痛点，据此引出关于codeReview的职责和价值探讨，达成一致后，再讨论下面的方案

我们不能为了cr而cr(下文简称codeReview为cr)，那就很没意思了

之前我们主要是在上线前以会议的方式，集中进行cr

最大的痛点：基础问题消耗了很多的时间与耐心，大部分时间都在争论诸如代码风格、编码规范、代码逻辑等比较基础且重复出现的问题(比如命名、日志、异常处理等等)

当然了，还有些其他的痛点，后续会有介绍，这里就不展开了

反思：cr不应该成为保证代码风格和编码规范的手段，也不应该承担发现代码bug的职责，每个人提交review时，代码就应该是符合规范的、充分自测过的，这是默认值，是每个人自己的事

(ps:这不是说不能在cr中报告这些问题，只是说这不应该是cr的意图)

所以我们既然要搞cr，就不能用上面说的基础问题来分散了cr的注意力(这些问题应该由其他方案来保证，下文会说明)

职责与价值：cr的主要精力应该集中在代码的设计、可读性、可扩展性、可维护性、可复用性、耦合性。。这些方面

在发现和讨论这些问题的过程中实现知识共享，提升个人工程能力，同时提高代码质量

你会发现，可读性、可扩展性、可维护性、可复用性、耦合性等概念随处可见，他们都是评价代码质量的常用标准，是程序员内功的基本体现，也是写代码的终极目标，但是..真的好抽象啊！

如果可以在实践中不断讨论、思考这些问题，就可以最直接有效的加深对它们的理解，提高自己的工程能力，对个人来说，这就是cr的最大意义吧

好了，意义明确了，开始介绍方案吧

cr方案

试点项目

实行一个新的方案，试图上来就全面开展，难度不小，团队规模越大，这点尤为明显。可以选择一个试点项目，运行良好后再逐渐推广

项目选择上，应结合团队实际情况，如项目参与人数、人员能力高低、项目迭代周期、代码量等

reviewer人选(谁可以审查别人代码)

原则上所有开发人员都可以审查其他人的代码，这有助于塑造团队的技术氛围，但是编码能力会影响到review的效果，如果前期效果不好，可能导致方案夭折

所以前期选编码能力好的人，慢慢过渡成所有人

这也是检验cr效果的一个标准，如果符合预期，大家的工程能力一定是越来越好的，最终都能作为reviewer

由于前期reviewer人少，所以任务会重一点，能者多劳嘛，不过得让leader对此心里有数，多劳多得嘛

审查工具

取决于团队使用的代码托管工具，我司用的是gitlab，所以我们就基于gitlab，通过merge request在线审查、写comment、驳回、通过等操作来执行审查，可以满足我们的要求，就是分支合并操作多了些..

gitlab以外，市面上流行的像google开源的gerrit，facebook开源的phabricator，都是既可以代码托管、又可以代码审查的，你可以调研下

审查人数

分为一对一审查和大家一起审查两种方式，大家一起审查只能以会议的方式开展，存在会议固有的问题，需要所有人同时抽出时间、容易跑偏，而且会议上跟着coder的节奏看代码，审查质量往往难以保证

所以主要还是以一对一的形式审查，相对来说，reviewer可以按照自己的节奏，时间更自由，审查的质量也由其自行把握

会议方式也可以有，但主题就不完全是review了，还带有一定的分享性质

审查时机

设计时审查+代码入库前审查+代码入库后审查

设计时审查：

在设计阶段进行审查，主要是讨论代码的架构、设计、核心流程是否有问题，这些问题往往影响很大，提前发现可以有效避免后期返工、甚至推倒重来

在会议内容方面，应该尽量详细的展示设计思路和实现思路，包括架构设计、表设计、用例图、流程图等，核心流程最好附有类图

这些都是自由选择，不作具体限制，但原则是尽量全面的评审到设计方案、甚至是实现方案，也可以让reviewer充分了解后续要评审代码的上下文

至于代码是入库前还是入库后审查，这取决于是提测前还是提测后

提测前：代码不着急入库，reviewer可以在一定时间范围内自由选择时间审查代码，要求在入库前审查

这就要求coder不要等到快提测了疯狂提交review，而是每开发完一个小功能就提交

通常情况下，自测良好的代码，提测前的代码量远大于提测后的代码量，所以大部分代码会在入库前被审查

提测后：代码着急入库，要求入库前审查不太现实，只能入库后审查

对于gitlab用户来说，为了方便后续review，提测后也要求提merge request(可以自己提给自己)，要求上线前reviewer找时间审查掉，如果是其他工具也要想好提测后的审查方案

审查范围

日常增量代码审查+定期全量代码审查

有些cr资料上还提出了审查范围的概念，分为增量代码审查和全量代码审查，平时的审查肯定是增量的，然后可以定期的检索存量的代码去审查

我们的做法是：定期举行晒码会，由负责人从存量代码中检索其认为可以优化的代码，在会议上发起讨论，并在会后修改上线

结合定期全量检索的方式，可以有效提高不良代码的曝光率和改善率

cr效率

为了提高review的效率，以及reviewer的幸福感，有必要提出一些要求

代码基本质量保证

文章开头说了，每个人提交review时，代码就应该是符合规范的、充分自测过的。就称它为"代码基本质量保证"，如何实现呢

规范是保证团队代码整齐度的重要手段，也可以避免很多低级问题，可以分为基础规范和团队规范

基础规范是通用的、可以由静态代码扫描工具扫描出的规范问题，不同的语言一般都有对应的扫描工具，像java的sonarlint，findbugs，p3c等

每个团队至少应选择一个静态扫描工具，并在团队宣传或者强制执行，要求在提交review前，coder已经解决了基础规范问题

有些公司会将这类工具和CI流程结合在一起，构建后触发静态扫描，不满足规范就不予通过，相当于强制执行了

团队规范是根据公司、团队自身情况定制的规范，比如分层习惯、公共API使用约束，线程池使用规范等

对此应该形成在线文档，长期维护，同样是多加宣传或者强制执行，要求coder保证代码是符合团队规范的

如何保证充分自测？只能是单元测试了，又是一个让人头痛的话题，就不展开了。总之，我们的原则是在提交前尽量减少bug

git commit质量要求

commit原子性、代码行数：commit原子性是指一个commit只做一件事，是一个不可分割的feature/fix/improved，在满足原子性的基础上，要求commit的代码行数不要太多(我们的标准是500行内)

commit说明：要求在commit说明中尽可能明确的表达提交代码的上下文，有些公司推行commit说明模板，你也可以参考

总之，不论哪种审查工具，都是依赖于git commit进行的，原子性、代码行数、说明这些都会直接影响审查者的体验，试想一下审查者看到一堆杂乱无关联的代码、上千行代码、逻辑复杂但毫无说明的代码时是什么感受

对于gitlab用户来说，commit之上还有merge request，一次merge request包含一个或多个commit，审查者基于merge request进行审查，所以merge request的频率和代码行数也要控制，这个没有标准，按团队情况来定

cr定期回顾与总结

开始实施cr流程后，定期回顾是非常必要的，防止走偏

可以通过人工调研+工具统计的方式跟进review的实际落地情况，持续优化

人工调研：通过访谈的方式，收集coder和reviewer在cr过程中遇到的问题、意见

工具统计：主流的cr工具都提供了众多可用于统计各类事件的api，比如commit大小、频率、意见数、驳回数等，这些指标可以帮我们发现很多问题

如何在团队开展codeReview相关推荐

敏捷开发中的Code Review
敏捷开发中的Code Review 一些敏捷团队在实施敏捷开发中忙于编码.忙于Unit Test.忙于沟通.忙于Build等,虽然也有编码审核阶段,但大都浮于表面,流于形式,效果不佳.本文结合实践,介 ...
一名“企业定制化人才”的自诉：“我不愿意，但却无可奈何”
这是头哥侃码的第214篇原创几个月前,我曾在大智慧时期的一位同事跟我聊微信,说自己所在的公司这两年业务一直不温不火,而且从19年底就逐渐缩减技术人员. 今年上半年又因为疫情的关系,公司干脆直接砍掉了 ...
实战工作十年的Code Review方法论与实践总结
作为卓越工程文化的一部分,Code Review其实一直在进行中,只是各团队根据自身情况张驰有度,松紧可能也不一,这里简单梳理一下CR的方法和团队实践. 一.为什么要CR 提前发现缺陷在CodeRe ...
阿里是如何做Code Review的？
作为卓越工程文化的一部分,Code Review其实一直在进行中,只是各团队根据自身情况张驰有度,松紧可能也不一,这里简单梳理一下CR的方法和团队实践. 一.为什么要CR 提前发现缺陷在CodeRe ...
软件测试周刊（第34期）：一岁有一岁的味道，一站有一站的风景
编辑:国薇.一口锅.菜菜.静怡.小淑子.夏至欢迎来到第 34 期!这里记录过去一周我们看到的软件测试及周边的行业动态,周五发布. 本期看点:腾讯是怎么做流量录制回放的?阿里的灰度方案是怎么设计的?下 ...
暑期档来临国产电影能否带给观众惊喜？
2017年已过半,在盘点完电影市场出现的佳片与烂片之余,难免要展望一下下半年.鹿豹座小编留意到,有一大波暑期档电影即将上映,下面就一起来看看有没有你期待的. 动作类今年暑期档势头最猛.看点最足的几部 ...
前端代码规范（1）谈code review
前端谈code review 一.review代码的认知 1.code review目的保证代码可读性,一致性代码层面减少bug,最基本缺少控制判断.异常处理传播知识+设计讨论. 相信很多人第一 ...
成就高效DevOps团队的“降龙十八掌”第一式——codeReview？
什么不是codeReview Code reviews 不应该承担发现代码错误的职责. Code Review主要是审核代码的质量,如可读性,可维护性,以及程序的逻辑和对需求和设计的实现.代码中的bu ...
如何在团队中做好Code Review
一.Code Review的好处想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处 1.互相学习,彼此成就无论是高手云集的架构师团队,还是以CURD为主的业务 ...

如何在团队开展codeReview

背景说明

好了，意义明确了，开始介绍方案吧

cr方案

cr效率

如何在团队开展codeReview相关推荐

最新文章

热门文章