团队Leader存眷你是否完成了义务，前后端架构师存眷是否相符公司同一的架构、风格、质量，产品架构师大年夜全部产品层面来存眷这个PR。
熟悉此问题的同事可以更好的包管问题被解决，确保没有惹人新问题。
被影响的同事可以及时懂得他受到的影响。
团队Leader或者产品架构师如不雅认为PR邀请的审核者不足或者过多，必须调剂为合适的人员，其它同事可以在评论中建议。
三、收成
我们在团队内部倡导质量优先，开辟团队不克不及为了进度就义质量，并在团队内部杀青了共鸣。
我们团队实施Code Review收成不少，总结出来大年夜概有以下几点：
1、短期内敏捷进步了代码质量。
原因有几个，大年夜家知道本身的代码会被人审核之后写得会比较卖力。
理论上代码质量是由全部团队内最优良的那小我决定的。
大年夜家也能在Review的过程中进修到其它同事优良的编码。
2、Bug数量敏捷削减。
然则这个我们没稀有据统计比较，比较遗憾。
这点进步了全部团队的幸福感，大年夜家不消经常被火烧眉毛。
3、团队成员对项目标熟悉程度会比较均衡。
新同事经由过程介入Code Review能很快熟悉团队的规范。
代码不会只有个别人懂得、熟悉，Bug谁都能改，新功能谁都能做。
这些PR一共产生了30040个评论，平均每个PR有4.32个评论，最多的一个PR有239个评论。
对公司来说避免了人员的风险，对小我来说比较轻松（谁都能来帮你），可以选本身爱好的义务做。
我们所懂得到的支撑PR模式的软件都采取Git作为源代码版本控制对象，所以我们的源代码版本控制对象也迁徙到了Git。
4、改良团队的氛围
Review的过程中会须要异常多的沟通，多沟通能拉近团队成员的距离。
并且无论级别高低，大年夜家的代码都是要经由Review的，可以在团队内营造一个平等的氛围。
每个成员都可以审查别人的代码，这很轻易激发他们的积极性。
最后，慢慢的形成了一种氛围，全部团队都邑自发的保护它。
亮一下我们的数据:
我们大年夜2014年1月17日开端第一个PR的提交，到2016年7月5日一共发出了6944个PR，个中6171个经由过程，739个拒绝。日均11.85个PR，最多的一天提了55个PR。
介入上述PR评论的同事一共有53位，平均每位同事发出了539个评论，最多的用户发出了5311个评论，起码的发了1个（刚履行Code Review就离职的同事）。
须要解释一下，只有简单的问题会经由过程评论来提出。比较复杂的，比瘸梨及到架构、安然等方面的问题，其实都邑面对面的沟通，因为如许效力更高。
四、总结
固然有合适的对象支撑会更轻易实施Code Review，但它本身并不特别依附具体的对象，所以前文并没有具体指明我们用了什么对象，除了Git。
经由简单的比较、试用，我们最后采取了Git Flow+Pull Request（PR）模式来做Code Review。（PR模式详情可拜见 Git工作流指南：Pull Request工作流）
原因是基于分支的PR流程依附于大年夜量创建分支，而Git创建一个分支异常的简单，所以PR模式+Git是一个很好的搭配。
我们在切换到Git之前，也做Code Review，采取的是提交卸码今后把commit的Id发给相干同事来审查的流程。
审核经由过程今后会在缺点跟踪治理体系琅绫擎评论，QA同事没见到审核经由过程的评论就认为义务没有完成，拒绝进行测试。
提交PR时刻有一个描述框，内容会主动根据Commit的message归并而成。
固然没有如今如许直接便利，然则也照样做起来了。
PR审核的过程中，新参加的团队成员常见的问题是不相符代码规范之类的，其实是可以经由过程源代码检查对象来解决的，这部分我们一向在筹划中（( ╯□╰ )），并没有开端实施。
【编辑推荐】
- Javascript中的神器——Promise
- DOM中Property和Attribute的差别
- TTPPRC贸易模型，30分钟拥有MBA的贸易分析才能
- 小Printf的编程故事：第一章
- 小Printf的编程故事：第二章
推荐阅读
【技巧沙龙】AI开辟者拭魅战营-7分钟打造1个定制技能。7月22号，我们等你一路！ 这种 MVC 架构模式对于简单的应用来看起是OK 的，也相符软件架构的分层思惟。 但实际上，跟着H5 的赓续成>>>详细阅读
本文标题：我们是怎么做Code Review的
地址：http://www.17bianji.com/lsqh/36317.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示