# 不可或缺的 Code Review 环节！如何实施？
众所周知，Code Review 是开发过程中一个非常重要的环节，但是很多公司或者团队是没有这个环节，或者说不重视这个环节，今天我们结合实际情况来谈谈 Code Review 的价值以及如何实施。
# Code Review 的价值
许多团队没有 Code Review 环节，或者因为追求项目的快速上线，认为 CR 浪费时间；或者团队成员缺少 CR 观念，认为 CR 的价值并不大。所以想要在团队内推动 Code Review 的实施，最最重要的一点便是增强团队成员对 Code Review 环节的认同感。
Code Review 环节，它更依赖于团队成员的主观能动性，只有团队成员对其认可，他们才会积极主动参与这个环节，CR 的价值才能最大化体现。如果团队成员不认可 CR，即使强制设置了 CR 流程，也是形同虚设，反而可能阻碍正常开发流程的效率。那么如何让团队成员认可 CR 环节呢，自然是让他们意识到 CR 的价值，然后就会 ... 真香！
# 提升团队代码质量
随着团队规模的扩大和项目的迭代升级，团队之间的信息透明度会越来越低，项目的可维护性也会越来越差，可能引发一系列问题：
- 已有的 utils 方法，重复造轮子
- 代码过于复杂，缺少必要注释，后人难以维护
- 目录结构五花八门，杂乱不堪
...
合理的 CR 环节可以有效的把控每次提交的代码质量，不至于让项目的可维护性随着版本迭代和时间推移变得太差，这也是 CR 的首要目的。 CR 环节并不会降低开发效率 ，就一次代码提交来说，也许部分人认为 CR 可能花费了时间，但是有效的 CR 给后人扩展和维护所节省的时间远超于此。
# 团队技术交流
Reviewer 和 Reviewee 在参与 CR 的过程中，都是可以收获到许多知识，进行技术交流的。
- 有利于帮助新人快速成长，团队有新人加入时，往往需要导师带领一段时间，通过 CR 环节，可以使导师最直接了解到新人开发过程中所遇到的问题，做出相应的指导
- 通过 CR 环节，团队成员可以了解他人的业务，而不局限于自己所负责的业务范围。项目发现问题时，可以迅速定位到相关业务的负责人进行修改，同时若有团队成员离职，也可以减少业务一人负责所带来的后期维护问难的问题。
- 学习他人的优秀代码。通过 CR 环节，可以迅速接触到团队成员在项目中解决某些问题的优秀代码，或者使用一些你所未接触过的 API 等。
# 保证项目的统一规范
既然要进行 CR，首先要对项目的规范制定要求，包括编码风格规范、目录结构规范、业务规范等。一方面，同意的项目规范才能保证项目的代码质量，提高项目的质量和可维护性；另一方面，在大家熟悉了统一规范之后，能够提升 CR 的效率，节省时间。
# Code Review 的实践
关于 Code Review 的实践，要考虑的包括 CR 所花费的时间、CR 的形式、何时进行 CR 等等。
# 预留 CR 的时间
首先不得不承认，CR 环节是要耗费一定时间的，所以在项目排期中，不仅要考虑开发、联调、提测、改 bug 等时间，还要预留出 CR 的时间。包括担任 Reviewer 和 Reviewee 角色的时间都要考虑。另外如果遇到需求比较复杂，为了避免因为 CR 过程导致代码需要大量修改，最好提前和团队成员沟通好需求的设计和结果思路。
# CR 的形式
我所见过的 CR 大多有两种形式。一种是设立一个特定的时间，例如周会，团队成员一起对之前的 MR 进行 CR；另一种是对每一个 MR 都进行 CR。
我个人更加推荐后者。第一种定期 CR，如果 MR 的数量太多，不太可能对所有的 MR 进行 CR，如果 CR 之后再对之前的 MR 进行修改的成本太大，而且一次性太多的 CR 会打击团队成员的积极性。第二种 CR 就相对来说轻松一些，可以考虑轮流对 MR 进行 CR。
# CR 的时机
CR 的环节应该设立在提测环节附近。因为 CR 后如果优化代码虽然理论上只是代码优化，但可能会不小心动到业务逻辑，如果是提测之后再进行 CR 很有可能会影响到已经测试过的功能点。
当然也可以分情况，如果遇到比较紧急的需求或者 bug 修复，那么也可以先提测，后续再做相应的 CR。
# 对团队成员的要求
前面已经提到，要增强团队成员对 CR 环节的认同感。作为 CR 环节的参与者，还应该根据自己团队的特点，对团队成员做出相应要求。
# Reviewer
- 指明 review 类型。reviewer 给出相应的代码评论时，建议指明评论的类型，可以在评论前用 [] 做出标识，例如：
[request]xxxxxx此条评论的代码必须修改才能予以通过[advise]xxxxxx此条评论的代码建议修改，但不修改也可以通过[question]xxxxxx此条评论的代码有疑问，需要 reviewee 进一步解释
- 讲明该评论的原因。在对代码做出评论时，应当解释清楚原因，如果自己有现成的更好的解决思路，应当把相应的解决思路也写上去，节省 reviewee 的修改时间
- 平等友善的评论。评论者在 review 的过程中，目的是提升项目代码质量，而不是抨击别人，质疑别人的能力，应当保持平等友善的语气。
- 享受 Code Review。只有积极的参与 CR，把 CR 作为一种享受，才能将 CR 的价值最大化体现。
# Reviewee
- 注重注释。对于复杂代码写明相应注释，在进行 commit 时也应简明地写清楚北京，帮助 reviewer 理解，提高 review 效率。
- 保持乐观的心态接受别人 review。团队成员的 review 不是对你的批判，而是帮助你的提升，所以要尊重别人 review，如果 review 你感觉不正确，可以在下面提出疑问，进一步解释。
- 完成相应的 review 修改应当在下面及时进行回复，保持信息同步。