乐趣区

关于前端:不可或缺的Code-Review环节如何实施

jiezi

家喻户晓，Code Review 是开发过程中一个十分重要的环节，然而很多公司或者团队是没有这一环节的，明天笔者联合本人所在团队，浅谈 Code Review 的价值及如何施行。

1. Code Review 的价值

许多团队没有 Code Review 环节，或者因为谋求我的项目疾速上线，认为 CR 浪费时间；或者团队成员短少 CR 观点，认为 CR 的价值并不大。所以想要推动 CR 在团队中的施行，最最重要的一点便是加强团队成员对 CR 环节的认同感。

Code Review 环节，它更加依赖于团队成员的主观能动性，只有团队成员对其认可，他们才会踊跃地参入这一环节，CR 的价值能力最大化的体现。如果团队成员不认可 CR，即便强制设置了 CR 流程，也是形同虚设，反而可能妨碍失常开发流程的效率。那么如何让团队成员认可 CR 环节呢，天然是让他们意识到 CR 的价值，而后就会……真香！

1.1 晋升团队代码品质

随着团队规模的扩充和我的项目的迭代降级，团队之间的信息透明度会越来越低，我的项目的可维护性也会越来越差，可能引发如下一系列问题：

  1. 已有的 utils 办法，反复造轮子
  2. 代码过于简单，短少必要正文，前人难以保护
  3. 目录构造形形色色，杂乱不堪

……

正当的 CR 环节，能够无效地把控每次提交的代码品质，不至于让我的项目的可维护性随着版本迭代和时间推移变得太差，这也是 CR 的首要目标。
CR 环节并不会升高开发效率，就一次代码提交来说，兴许局部人认为 CR 可能破费了工夫，然而无效的 CR 给前人扩大和保护时所节俭的工夫是远超于此的。

1.2 团队技术交换

Reviewer 和 Reviewee，在参加 CR 的过程中，都是能够播种到许多常识，进行技术交换的。

  1. 有利于帮忙新人疾速成长，团队有新人退出时（如实习生和校招生），往往须要认为导师率领一段时间，通过 CR 环节，能够使导师最间接的理解到新人开发过程中所遇到的问题，作出相应的领导。
  2. 通过 CR 环节，团队成员能够理解别人的业务，而不局限于本人的所负责的业务范围。我的项目发现问题时，能够迅速定位到相干业务的负责人进行批改。同时若有的团队成员到职后，也能够缩小业务一人负责所带来的前期保护艰难。
  3. 学习别人的优良代码。通过 CR 环节，能够迅速接触到团队成员在我的项目中解决某些问题的优良代码，或者应用的一些你所未接触过的一些 api 等。

1.3 保障我的项目的对立标准

既然要进行 CR，首先要对我的项目的标准制订要求，包含编码格调标准、目录构造标准、业务标准等等。一方面，对立的我的项目标准能力保障我的项目的代码品质，进步我的项目的品质和可维护性；另一方面，在大家相熟了对立的标准后，可能晋升 CR 的效率，节省时间。

2. Code Review 的实际

对于 Code Review 的实际，要思考的包含 CR 所破费的工夫、CR 的模式、何时进行 CR 等等。

2.1 预留 CR 的工夫

首先不得不抵赖，CR 环节是要消耗肯定工夫的，所以在我的项目排期中，不仅要思考开发、联调、提测、改 bug 等工夫，还要预留出 CR 的工夫。包含负责 Reviewer 和 Reviewee 角色的工夫都要思考。

另外如果遇到的需要比较复杂，为了防止因为 CR 过程导致代码须要大量批改，最好提前和团队成员沟通好需要的设计和后果思路。

2.2 CR 的模式

我所见过的 CR 大多有两种模式。一种是设立一个特定工夫，例如每周或者每半月等等，团队成员一起对之前的 Merge Request 进行 CR；另一种是对每次的 Merge Request 都进行 CR。

我集体更偏差于后者。第一种定期 CR，Merge Request 的数量太多，不太可能对所有的 MR 进行 CR，如果 CR 之后再对之前的诸多 MR 进行批改老本太大；而且一次性太多的 CR 会打击团队成员的积极性。第二种 MR 绝对就轻松的多，能够思考轮班每天设置 2 - 3 人对当天的 MR 进行 CR 即可。

2.3 CR 的机会

CR 的环节应该设立在提测环节之前。因为 CR 后如果优化代码尽管实践上只是代码优化，但很可能会对业务逻辑产生影响，如果在提测时候，那么可能会影响到曾经测试过的性能点。

当然也要分状况，如果遇到比拟紧急的需要或者 bug 修复，那么也能够先提测，后续再做相应的 CR。

3. 对团队成员要求

后面曾经提到，要加强团队成员对 CR 环节的认同感。作为 CR 环节的参与者，还应该依据本人的团队特点，对团队成员做出相应要求，能够参考咱们团队。

3.1 Reviewer

  1. 指明 review 的级别。reviewer 再给相应的代码增加评论时，倡议指明评论的级别，能够在评论前用 [] 作出标识，例如：

    • [request]xxxxxxx 此条评论的代码必须批改能力予以通过
    • [advise]xxxxxxxx 此条评论的代码倡议批改，但不批改也能够通过
    • [question]xxxxxx 此条评论的代码有疑难，需 reviewee 进一步解释
  2. 讲明该评论的起因。在对代码做出评论时，该当解释分明起因，如果本人有现成的更好地解决思路，应该把相应的解决思路也评论上，节俭 reviewee 的批改工夫。
  3. 平等友善的评论。评论者在 review 的过程中，目标是晋升我的项目代码品质，而不是鞭挞他人，质疑他人的能力，应该放弃平等友善的语气。
  4. 享受 Code Review。只有踊跃的参加 CR，把 CR 作为一种享受，能力将 CR 的价值最大化的体现。

3.2 Reviewee

  1. 重视正文。对于简单代码写明相应正文，在进行 commit 时也应扼要的写分明背景，帮忙 reviewer 了解，进步 review 的效率。
  2. 放弃乐观的心态承受他人的 review。团队成员的 review 不是对你的批评，而是帮忙你的晋升，所以要尊重他人的 review，如果 review 你感觉不正确，能够在上面提出疑难，进一步解释。
  3. 实现相应 review 的批改该当在上面及时进行回复，放弃信息同步。
退出移动版