一、序言: 本来程序员是这么合作的
在我工作的前四年, 常常会在网上看到Code Review这个词. 可是却历来实践过.
看着他们关于Code Review习以为常的姿态, 我宛如活在了平行世界. 不知道他们在说什么, 尽管每一个字都知道, 天然也没有什么感触.
直到第五年,加入了现在的公司,才真正的知道Code Review是什么一回事. 或者说仅仅知道一冰山一角,毕竟到现在只有不到一年的Code Review的经验. 可是给我带来的感触仍是很深的.
向开源项目提交PR, 也有Code Review? 不好意思, 在此之前,历来不看其他源码,面向百度编程算了
这篇文章, 内容包含介绍什么是Code Review, 咱们组现在的Code Review流程, 接着到Code Review礼仪。 最终加上一个问题， 小公司是否需求Code Review。
关于最终一个问题,我想来仍是有必定的发言权的. 在工作的前四年换了六家公司, 去一家关闭一家. 并不是我想要换岗,仅仅普本的学历、菜狗的技能, 许多人瞧不起的外包我都面不过. 再加上命运着实有点问题。
所以在这些小公司协作的时分, 适当原始。 svn代码办理, 本地项目打包出dist文件夹, 紧缩之后经过QQ传给后台上传。 即使到了担任APP的时分, 也是本地手动打包出.app发送到测验手机上面.。
即使后来用了git,也和svn的使用没有任何不同, 不存在什么代码查看, 仓库权限的装备. PR和 MR是啥意思都分不清楚. CI和CD是啥？
我的本科尽管是计算机科学与技能,可是除了学习,啥都干。
直到来到了现在的这家公司, 才知道,本来程序员是这么协作的。之后再出一篇文章详细谈谈。
二、什么是Code Review
Code Review便是将自己的代码公开的给其他程序员查看的过程。
Reviewer和Reviewee之间主要是经过comment来进行交流，comment能够针对每一行来进行谈论。
- 了解搭档在编程时的考虑方法，这样其余搭档今后假如有需求就能够更轻松、快速的修正代码。
- 向搭档介绍修正了哪些文件，增加了什么样的功用，这样在问题出现时，能够保证至少有两个人能够协助诊断、处理问题。
2.1 谈论标准
comment也有标准，如下
1. [request] 我主张这里能够更改为函数forEach用户，这个愈加的复合标准
2. [advise] 这里的判别为了应对之后的扩展，能够考虑使用战略形式
3. [question] 为什么需求多加一个变量来进行判别
如下图的实际操作状况，在对应的代码下面点击谈论：
经过[]包住的标识意义仍是很直接的。
- [request] 必需求修正才能够经过
- [advise] 不修正也能够经过
- [question] 需求reviewee解释一下
2.2 CR是在R什么
意图是进步代码质量
提前发现bug外，还包含一致团队的代码标准，比方常常会碰到有人说你这个变量命名不对
代码风格经过装备Eslint来进行一致，命名规则，语法查看，分支标准等是需求提前团队标准来处理的。这些都不应该放在Code Review上面。
所以实际上，在CM之前是有前置条件的：
在这里之后才开端CM。CM的内容根本包含下面：
- 事务BUG
- 代码质量
事务BUG很直接，许多时分，写的东西不必定用在一个场合，而写的人不必定都了解。
代码质量包含这些内容：
- 人工查看代码格式化的漏网之鱼
- 是否存在重复
- 最佳实践，
if else、参数过多、ES6、规划形式（怼人的理论基础是《重构-改进既有代码》） - 命名可读性,能自我论述的最好,英文用词尽量准确(命名是一切程序员的头痛之一)
- 注释,适可而止的注释,重要的地方及时备注,不需求的地方要删除必定的注释信息,代码既是给机器运行的,也同时是交接给人看的.
- 代码是否强健，是否可扩展
咱们的目标是消除下面这张图：
三、咱们组的Code Review流程
咱们组是每一次Merge Request都进行Code Review。
还有一种是每隔一段时刻集中大家一起来进行CR。
根本的流程图如下:
简单来说，便是从test分支拉取最新的代码之后，开发完结之后需求合并到长途自己定义的分支，随后将这个分支申请合并到长途test分支上面，经过CI主动扫描之后，就动身代码查看阶段了
- name_需求编码指的是, 长途的分支的名称 = 是以自己的姓名的首字母 + 下划线 + 需求的ID。
- test分支在经过测验之后， 才会被允许合并到releasel分支， 这个过程是封版。将该分支发布布置之后，就能够合并到master分支。当然，这个触及到了分支战略的问题，今后再谈
咱们组最多的时分十个人, 评定的人员除了申请人, 其他人都是评定员. 每一个PR只需求两个评定的经过就能够入库。当有未必处理状况的谈论的时分，其他评定人一般状况是不能批阅经过的。
这样的评定的机制其完成已适当宽松了 ，也是期望一切人都能够参与到评定傍边，彼此都能够了解到对方模块的状况。
可是现实中状况仍是不太一样，由于人员之间的水平是有差距的，咱们的人员搭配是两个内部的搭配7/8个外包的伙伴。尽管平常开发现已一再说明能够给任何人查看代码，不过由于整个环境的问题，实际上敢点击经过代码的依旧只有内部的两个人。构成了事实上的两人评定。
四、Code Review礼仪
Code Review的礼仪决议了你是否会被搭档背后捅刀。主要是谨记一条准则：
只针对代码不针对人
4.1 总结
对评定人员的主张：
- 看不明白的时分，能够适当的提示对方增加注释
- 看不明白的时分，是请教对方而不是责问对方
- 不管是明确修正的计划仍是指出问题，给出自己的理由，依据，而不是感觉
- 谈论的内容不要过于广泛
作为reviewer提出comment,意图是提升项目代码质量，而不是打击他人，质疑他人的才能，应该保持平等友善的口气。
谈论的内容广泛的问题，比方说，谈论Reviewee的耦合度太高。这么的言论就很操蛋，咱们需求提出的是具体的主张，能够给出具体的改进的伪代码。否则最好闭嘴。
对提审人的主张：
- 每次提交的代码量都尽可能的小
- 辩驳必定需求给出的依据
- 相比评定人要愈加的谦善
榜首点，为了方便审阅者能够轻松了解代码中有哪些更改以及做了什么。假如 code review 的内容足够少，则能够更频频地进行，可能每天几次，并且更易于办理。
关于第二点，评定的人花了这么多时刻给你来看代码。假如提出的主张能够改进你写的代码，或者直接指出了问题，提审人都是最大的受益者。
4.2 话术的主张
| bad | good |
|---|---|
| 你要这么做 | 我主张这么做/这么干是否愈加好 |
| 你写的代码比较差 | 这块代码写得比较差 |
| 你这里写得太坑了 | 重构里面提议这种状况应该提取函数 |
最重要的一点便是，不要小气你的夸奖！
当你真实找不到问题的时分，多夸夸你的搭档吧。这段代码规划得真好，这段代码性能提升得真高。当然，平常做人的时分也应该如此。
五、小公司是否需求Code Review
不需求！
关于公司而言，事务榜首，产品第二，技能无所属。领导只关怀怎样活下去。所以关于你怎样使用技能并不关怀，关怀的是事务是否来钱，自己还有几套房能够抵押。
你们进行CR是需求时刻，这是钱。
你们想要进步代码质量，需求持续重构优化，客户操作界面的时分感受得出来么？假如没有，那是浪费钱。
无关褒贬，客观事实算了。
可是关于个人而言呢？需求，适当需求。
都不小了，要明白自己应该做什么。
假如团队的Code Review有没有推行没关系,有,天然是非常的。没有的话，你也要经过其他手法自我提升。
凡是有好的事物都应该主动去尝试,去坚持,战胜外来因素影响。
一个人,也相同能够Review自己和搭档代码,为的不是公司，为的是自己。
Review水平比自己高的，能够直接提升自己的编码才能，学习高水平的思路和规划。
Review水平比自己低的，能够看看那些错误都是怎样产生的，劝诫自己。
Review水平缓自己差不多的，能够换位考虑，假如是自己来完成会怎样完成。
卷起来吧，
放错图，应该是
本文正在参与「金石计划 . 分割6万现金大奖」
