？简介代码CR（CodeReview）是软件开发活动中保证平台产品质量的重要环节。相信很多技术团队平时都会进行代码CR。以阿里为例。一般来说，周二和周四是发布日。在某个功能发布上线之前，必须要组织一个代码CR来发布代码。CR不通过的代码必须经过修改和检查才能发布。工厂技术团队对编码CR的重视。代码CR虽然大家都很熟悉，但是在自己的团队真正实现的时候难免会遇到这样那样的问题。典型问题如下：1.到底是所有代码都需要CR，还是只有核心业务代码才需要CR？2、reviewer如何仔细review代码？3.线上CR还是线下CR？4.CodeCR需要大量的时间和精力。如何确保花费时间和精力后达到预期的效果？本文将与大家一起探讨如何在技术团队中高效开展代码CR活动，不至于让代码审查活动流于形式，走个流程。codeCR为什么能提升团队的代码水平？一般技术团队都是由不同技术水平、不同工作年限的同学组成的，而CodeReview是大家互相学习代码设计的一个很好的机会，因为在CodeReview的过程中，不仅会检查业务代码逻辑问题，还包括结构设计、程序性能、代码安全、程序健壮性等综合检查。因此，如果团队核心骨干能够大量参与代码CR活动，不仅可以帮助其他同学成长为一定程度上，还能帮助新同学快速融入团队。另外，在编码的时候，代码CR机制会像一只无形的手，不断督促团队成员不要写出糟糕的代码。因为大家都知道自己写的代码需要在团队内部公开CRed，所以压力会油然而生，也会鼓励自己不要写烂代码，因为大家都不希望自己写的烂代码暴露在前面每个人，所以我跟不上自己。所以CR机制在一定程度上可以让团队成员避免写一些短期盈利的代码，从而欠下以后维护同学的技术债。CodeReview不是什么高深的东西，而是程序员的技术炼金术。保证设计和实现的一致性在程序员的日常工作中，通常是在业务需求KO之后，再进行相应需求的设计和实现。但是在实际的研发活动中，实现和设计往往存在一定的偏差差距，而这些差距可能会导致后期上线时出现bug和代码维护问题，所以在代码CR的时候，一定要关注设计和代码之间的差异。实际实施，尤其是要求Owner应重点审核业务“设计”实施的一致性。统一团队编码标准在实际代码CR过程中，经验丰富的老司机会从命名、代码结构设计、程序性能等方面进行分析。其实同一个需求，让100个程序员去做，写出来的代码可能有100种不同的风格。我认为这是正常的。实现逻辑可以多种多样，但在一些通用的编码标准层面，需要统一。如果有这样的业务场景，你定义一个订单的DTO类，其中一个字段是订单的审核状态。假设有三种状态：待审核、审核通过、审核失败，我们通过定义一个枚举状态来表达差异。这里的inspectStatus对应枚举中的三个status属性。你认为下面的代码有什么问题？publicclassOrderDTO{.../***Auditstatus*/privateIntegerinspectStatus...}其实不是代码本身的问题（都是属性问题），而是可读性的问题。假设你刚刚接管了这个模块的职责。看到这个定义，是不是很想知道有什么样的reviewstatus，但是因为对代码不熟悉，不知道去哪里找，所以看了性能和可维护性都没有满意的。这种情况下，我们可以在reviewstatus字段的comment中添加一个@link，可以直接链接到对应的status枚举类，方便维护业务的同事通过实体类直接查看订单的review状态.比没有无头苍蝇的情况下在项目中寻找或询问其他组的同事效率更高。所以，我们在写代码的时候，不仅要考虑如何实现当前的需求，还要考虑如果以后别人维护我写的代码，如何让后续的维护同学更好更快的掌握业务逻辑。publicclassOrderDTO{.../***AuditStatus*{@linkcom.mufeng.eshop.biz.order.InspectStatusEnum}*/privateIntegerinspectStatus...}这里是一个看似简单的例子，但是在里面却很在实际编码中很常见，所以需要在团队中统一规定代码规范。代码规范级别请参考《阿里巴巴Java开发手册》，Idea有对应的插件AlibabaJavaCodingGuidelines。明确业务逻辑细节通常，一个技术团队可能负责多个不同的业务线。这些业务之间可能存在一定的关系。但是同学们平时忙于各种业务需求，你可能不太关注同组同学所负责的业务的具体逻辑细节。因此，通过代码CR，你可以有机会了解每条业务线的逻辑细节，让团队成员更容易理清上下游业务逻辑。当涉及到未来完整业务链的业务需求时，他们可以更全面地考虑，并在设计时确定一些关键的设计点。如何保证代码CR的效果想要保证代码CR的效果，我们需要搞清楚技术团队代码CR的效果会受到哪些因素的影响。这里大致总结一下日常工作中影响代码CR效果的因素：对于提交代码审查的同学：1.不知道提交代码CR的范围；2.不知道谁需要提交代码CR；3.如何让别人认真Review代码；对于review别人代码的同学：1.不清楚需要CR代码的业务上下文是什么，不容易判断代码结构设计的合理性；2.一次提交几千行代码，哪些代码是CRContent的重点，哪些不是；以上问题是制约技术团队代码CR实施效果最常见的问题。我们应该如何解决这个问题？在线审查与离线审查相结合在线审查一般是主要的代码CR方式，但是提交审查时必须遵循一定的原则，以提高代码审查的效率。1、每次CR提交的代码不要太多。如果每次review的时候一下子把几千行代码推给别人，估计相应的reviewer也不想看，review的质量也很难保证；2、提交审核时有时需要附上一定的说明，明确这些代码主要实现了什么样的业务需求，主要核心逻辑在哪些文件中，以便审核者在审核代码时有的放矢。线下复习是线上复习的重要组成部分，比如每周一到两次的线下会议复习一般就可以满足需求。在onlinereview之前，最好和reviewer敲定时间和需要review的代码，提前准备好需要CR的代码背景，比如对应的具体要求是什么，如何分析问题当代码被执行时。类结构是如何设计的等等，让审阅者清楚地了解代码的背景。另外线下review的代码量不要太大，时间尽量保持在一小时左右。评审会议期间，需要记录大家提出的建议和问题。会后会修改，然后和大家??确认。找到合适的codereviewer，将代码提交给合适的Reviewer进行review很重要，因为如果代码提交给没有业务相关或类似技术水平的Reviewer，对于没有业务相关或类似技术水平的同学来说会很难与业务相关的理解里面的业务规则代码，显得费时费力。另一方面，水平差不多，无法提出改进建议。因此，基本上很难获得较好的审稿结果。1、向团队中有经验的程序员提交CR，以获得更高级别的代码设计反馈；2.向业务需求负责人提交CR。需求负责人一般对这部分业务需求非常熟悉，所以可以从业务层面考虑或者在技术层面给出更好的建议；3.给修改过同一个文件的同学提交CR，让大家知道彼此的修改意图和原因，也便于评估影响范围。建立审稿奖励机制，可能是因为大家工作太忙，也可能是投给了不合适的审稿人。我们总是担心别人有没有认真CR过我们的代码，那么如何才能激励大家认真审查代码呢？这是一个可以付诸实践的机制。比如我们可以在团队内部建立明确的代码CR奖励机制，对在代码CR过程中审核的优质bug的审核者进行奖励（奖牌或者奖杯都可以，同时在P8以下的大团队会被通知表扬，提升影响力）。每个月都会选拔捉虫高手，注重数量更注重质量。通过这样的奖励机制，我们会积极引导大家积极进行代码CR。但是这里有一个隐含的bug，就是如果团队中有技术专家，那么大家可能都会把代码提交给他审核，所以技术专家的代码审核量会非常大。变成了甜蜜的包袱，所以还是有所取舍，比较重要的代码提交给技术专家审核，既保证了核心业务逻辑代码审核的权威性，又不给高级工程师在团队中的工作量。
