代码CR的那些事

提到CR大家都不陌生，谈到它所带来的好处相信大家都能脱口而出：减少代码缺陷、提升可读性、确保开发风格统一等等等等。CR早已是老生常谈了，大家都知道它在项目开发中以及个人成长都能带来不少收益（当然前提是保证整个过程的严谨规范），所有代码在入库前都应当进行严格的代码CR。做好代码CR就是防患于未然，降低产品上线风险。

为什么要做代码CR

      举个例子，正如木桶原理一般，取决于木桶能装多少水的决定性因素总是最短的那块木板，它直接定义了木桶的下限，此时短木板对长木板起到了制约和限制，降低了木桶整体的实力。同样的道理，一个人的思考终归是不够全面的，而与团队内其他人的共同协作，通过代码CR，提高代码的下限，在产品上自然是表现为提高了产品的可靠度，提升产品力。

CR带来的好处

为代码规范性提供保障

      每个人在开发过程中都有属于自己的风格，有着自己的编写喜好，在团队中，代码风格各异会导致整体可读性极差，所以CR过程中Reviewer应当熟练掌握团队所遵循的代码开发规范，严格把控此处CL的代码风格，保持仓库代码风格统一，杜绝个人偏好风格的出现。

      正是如此，有时候CR会让开发者感到相当难受——要使用自己不喜欢的方式书写代码，但是规范性往往不是以个人意见为依据，为了尽可能的保证质量，开发者有时几乎都没有选择的。

此处还可以分两个视角观察。

       从开发者的角度来看，CR中所需要遵循的规范可以避免开发过程中“偷懒”的行为，例如边界情况兜底trycatch、图方便使用硬编码等等。如此行为在开发过程中来说是极爽的，但是对于产品来说是非常危险的，非常有可能导致代码运行报错等情况，CR也因此你带来一种即时的反馈，阻止你去选择那些短期收益、长期损失的“投机”行为。从维护的视角来看，确保了将来再次维护这段代码的可读性，避免过于跳脱、随意的写法加重代码维护的难度，毕竟代码是写给人看的，只有其他人都能简单明了看懂的代码才是真正的好代码。

校验逻辑可行性

      当然了，保证代码执行的逻辑正确，是开发者的首要责任，出于对需求理解、编写思路等各方面开发者与Reviewer存在差异，reviewer不可能全然按照开发者的思路去分析带啊吗逻辑，也是如此，Reviewer以不同角度出发，可以更加全面的判断代码的逻辑是否存在覆盖面的漏洞。

发现潜在的bug

      代码CR确实也应该用来发现错误。本质上就是建立一种冗余机制，通过多人协同，利用人与人之间思维、认知的差异尽可能的发现一段代码中的错误，从而提前预警， 防止错误出现在生产中。

加强团队技术交流

      除却以上，CR对于加强团队技术交流、熏陶团队技术氛围而言也是有着不小的好处。

      通过代码CR，可以让开发人员之间彼此了解不同的产品业务功能、不同的代码实现方式，虽说仅通过CR就企图所有人都完全熟悉这个需求、模块并不现实，但是至少可以让其他人接触、了解到，加强团队内部紧密合作的联系感。

如何高效的做好代码CR

定义好统一的风格规范

       俗话说，无规矩不成方圆。如果团队内部没有一份统一的代码规范，那么 review 过程中如果出现代码风格意见偏离的情况那么就会没有无法迅速达成一致，会阻挠CR进展，影响效率。所以在开发前，团队内的所有开发人员都应当熟悉并且遵循同一份标准，做到“有迹可循”。

把握好发起时机

       开发过程中尽可能的提前发起CR，整个过程小步快跑。不少开发者都习惯于将业务功能开发完毕后一次性提交CR，这种方式看似合理省事，却是不健康的。代码CR对于开发者而言需要随时做好调整甚至重构的准备，这个环节会导致整个发布期限延长，所以尽可能提前的发起CR，一定程度上可以有效降低CR被打回导致的发布周期延长的问题。

控制代码量

       每次提CL时要保证代码的行数，比如保持在400行内，这一步是为了确保 Reviewer 评审时的效率及准确度。试想，一次性CL如果达到1000行的话，对于 Reviewer 而言无疑是一个巨大的挑战，需要承受极大的心理负担，完整的 review 一遍的难度无异于进行一次开发，而且一次性大批的代码量也会很大程度的影响 review 的准确性，如果是改动量大、逻辑复杂的一次CR，那么将所有产出一次性抛出，对于Reviewer而言是一次灾难性的，极具加重了CR的工作难度。更甚者如果面临CR被打回需要重构代码时，庞大的体量对于开发者而言也是不小的压力，可能涉及重新开发、重新验证、再次review大体量改动甚至导致需求延期发布等等而代码量少的好处则是显而易见的：修改部分清晰名了，问题也是一目了然，整个 review 过程下来会非常的清爽舒适，也可以保证 review 的准确性。

制定CR CheckList

      这个过程在初期看似比较繁琐，但是CR过程中需要注意的环节往往是比较复杂，review 中容易忽略某些细节部分，可能导致CR不够充分使代码的规范、安全无法得到保证，所以一份CheckList对于初期帮助提升CR的完整性有着重要提示作用。另外CheckList也不能始终不变，随着产品迭代、技术更新也需要对CheckList不断地维护补充。

提交review之前，严格的自我检查

      不少人会忽略这一步，代码CR并不是把代码的质量把控这一环节全权交给他人，开发者始终是代码的首要负责人，确保代码在交出去的那一刻是最完美的应当是每一个开发者必要的操守。Reviewer 只是帮助开发者把关，提出更多细节上的优化，而不是开发者代码质量的负责人。不经检查的一次CR，不仅是开发者工作的失职，也是对于Reviewer时间的浪费。

尽可能及时响应

      对于开发者而言，发起CR后Reviewer越是及时的响应越能提高CR流程的整体效率。当然这一步是建立在前面的基础上，只有在确保了每次review的粒度不会过于庞大、有着严重的遵守规范等，才能达成Reviewer的及时响应。

建立团队良好CR环境

      由于CR依赖于所有队内成员的主观能动性，所以团队整体氛围营造相当重要。不能再是空对空的无代码式、纯理论式讨论，应该在实际问题中产生思考的碰撞。比如经常性的开展线下CR研讨会，大家一同对某个需求中的代码进行CR，彼此间的交流使队员能够互相学习，提高编码水平，以期团队内每个成员都掌握团队里积累出来的最佳实践。通过这个过程让团队开发人员在这个过程中学会高效阅读他人代码，提高代码质量，减少一些不必要的错误，并在团队内部达成了共识，最后能在团队内慢慢形成一种良好氛围，从而每个人都能自觉去维护它。