作者：京东物流 冯志文

前言

本文参考《京东 JAVA 代码规范-V1.1》&Google 代码评审工程实践方法论，结合团队代码评审的实践经验整理成文档，这份文档是我们团队集体经验的结晶。 我相信公司其他部门也有类似的经验和最佳实践。希望通过互相交流和学习，共同提高代码质量，进而提高系统的稳定性。

名词解释：

CL： “changelist”修改列表，它是提交到 coding 版本控制工具中的一次代码修改（即将审核的代码）

CR：CodeReview 代码评审

一、为什么需要 CR

代码质量是软件质量的基石

1.我们进行代码评审的目的是为了提升代码质量，尽早发现潜在缺陷与 BUG，降低修复成本。同时，这也有助于促进团队内部的知识共享，帮助更多人更好地理解我们的系统。

2.从系统的角度来看，代码审查可以帮助我们提前发现问题，减少 bug，提高稳定性，避免到处救火的情况发生。

3.从开发人员来看，代码评审是一个逐步改正不良习惯的过程，可以提高编码、设计、架构能力。让他们从自身犯过的错误中学习，并从他人的思路中成长。

4.从评审者来看，这也是一个学习他人编码能力的机会。我们可以从他们的经验和技巧中汲取养分，不断提高自己的专业素养。

5.从团队管理来看，代码评审提高团队凝聚力，熟悉彼此的模块业务。这将使我们更加团结协作，降低因人员流失带来的成本和风险。

......

请记住，代码评审不是批斗会。我们的目标是针对代码本身，而不是针对人。 我们应该以建设性的方式提出问题和改进意见，以帮助开发人员提高编程技能和整体水平。

最后，请确保团队所有开发者都理解并接受这个流程。如果团队有人对此产生抵触或反感，那么这个目的就无法实现。小组刚开始代码评审也是这样，大家总觉得不好意思指出别人的不合理之处。因此，请大家共同努力，让代码评审成为我们团队文化的一部分。

二、CR 流程规范

CR 前提条件：

1.本地通过 IDEA 各种插件检查一般性的错误。比如使用 JoyCoder、京东编码规约、Sonar 等

2.自测通过，确保基本功能流程没问题

将 CR 前置，避免到最后上线的时候合并到 Master 做 CR。履约需求上线 CR 至少经过 2 轮，第一次是提测前，最后一轮是上线前。每一轮的侧重点不一样。流程如下：

备注：Dev 分支主要作用 local 代码库的远程备份，这个备份动作是通过不断 commit&push 完成，所以不用担心代码丢失。Feature 分支承担功能测试和 CR 的作用，因为有 Dev 一层屏蔽了中途反复地修改，使得提交地 PR 更为清晰。Master 是上线使用的分支。

第一次 CR：

项目提测前（合并到 feature 分支）

1.为什么是测试前？

2.如果都测试完成了要上线了，CR 的意义在哪里？CR 发现的很多问题还改不改？

3.提测前 CR 反馈的问题细致全面，研发可以及时修复。

中间 CR：

（合并到 feature 分支）

1.主要是修复测试提的 BUG 之类，或者这个需求很久了，需要重新拉取最新的线上代码 master

最后一次 CR：

上线前（合并 master 主干）

1.这时候核心是 CR 代码冲突，代码是否有遗漏，配置是否准确？上线是否有其他风险点？

切记代码上线前的最后一次 CR 后，务必需要经过测试回归验证，引流验证等，以防合并代码遗漏等情况。对上线前代码再次回归验证没问题后才可以上线

代码评审 整个过程 分为 评审者和开发中。接下来分别解释下评审者指南和开发者指南。

三、代码评审者指南

在进行代码评审时，我们可以从不同的角度出发，包括评审者和开发者的角度来进行。

首先，从评审者的角度来看，我们需要了解一些评审的指南。这些指南包括：

1.哪些人可以参与代码审核？

2.评审方式有哪些？标准是什么？

3.评审者应该关注哪些？

1、哪些人可以参与代码审核呢？

1.小组长 TL： 从团队角度出发，需要有全局观，重点关注【稳定性】【代码可读性】等

2.架构师： 从系统架构出发，核心关注【代码思路是否和架构设计一致】

3.核心骨干： 为了确保代码质量和项目稳定性，我们通常会选择团队中最优秀的代码审核者来进行审核。这个人应该具备足够的经验和技能，能够在你期望的时间内对审核工作负责。

4.团队成员： 如果长期是核心骨干 CR，这样会导致团队其他人员参与度不高，需鼓励团队其他成员参与代码审核

前提条件

1.作为评审者，我们需要对项目的需求和设计文档有充分的了解，以便更好地理解代码的目的和实现方式。

2.评审者需要对评审的代码负责，而不是不看直接 merge 通过之类。

注意事项

1.有时候一个代码审核者无法覆盖整个 CL，因为其中可能包含太多的代码文件或者需要不同的技术背景来理解。在这种情况下，我们需要多位审核者参与审核，以确保能够覆盖所有的代码文件。我们应该考虑使用多个审核者来互相检查和验证代码质量，从而减少潜在的错误和漏洞。

2.不建议刚加入团队成员不足 3 个月并且还不熟悉业务的新人，具体可根据团队情况考虑。

2、评审的方式有哪些？

1.线上 Coding 平台（占比 90%）： 这种方式优点是京 Me 自动通知方便快捷，可以节省时间和成本。但是需要注意的是，由于 Coding 平台缺乏 Idea 其他内容上下文，前期评审者可能不太习惯，需要慢慢适应。

2.线下评审

1.面对面审核（占比 5%）：适合改动较小， 这种方式的优点是有疑问时可以随时提问并得到解答，可以直接了解开发者的思路和意图，有助于发现更深层次的问题。但是需要注意的是，这种方式需要耗费较多的时间和精力。

2.团队组会审批（占比 5%）：对于大型项目需求或者黄金核心链路有风险的需求， 除了线上评审外，我们可以线下再次 Review 把控。线下的核心是把控上线风险点（Joyspace 列出相关事项），通过团队内部的讨论和协作来提高代码质量。这种方式的优点是可以充分发挥团队的力量，共同解决潜在问题。但是需要注意的是，由于参与人数较多，可能需要较长的时间来完成评审过程。Promise 遇到牵扯较大、核心链路风险高的需求会采用线下 Review 风险事宜。

总之，在选择代码审核方式时，我们应该根据具体情况进行选择。同时，我们也应该注意及时反馈评审结果和建议，以便开发者能够及时修正问题并提高代码质量。

3、CR 的标准是什么？

代码审核的目的是保证持续改进代码库质量。

1.原则上，如果提交的代码能显著提高质量，即使不完美也批准。

2.审核者应分享知识，写一些有助于学习的评论。

3.涉及设计的问题应基于原则权衡，而非个人喜好。

4.如果没有规则，让作者与现有代码保持一致，不恶化系统质量。

4、代码审核步骤有哪些？

1.全面了解 CL 背后（需求、技术改造）。这个 CL 是否有意义？它是否包含好的描述？

2.综观整个 CL 中最重要的部分。从整体来看，设计是否合理？

1.找到包含 CL “主体”部分的文件。通常，如果一个文件包含大量的逻辑修改，那么它就是 CL 的主体部分。先审视这些主体部分有助于为其他部分理出上下文。如果 CL 太大，很难找到主体部分的位置，可以征询开发者的建议，你应该先看哪些部分，并建议他把一个 CL 拆分多个小 CL，小步快跑（功能独立的可设置为一个小 CL。比如 web 页面操作的分为一个小 CL，定时任务 Task 相关的是一个小 CL，API 接口部分是一个小 CL）

2.如果发现 CL 中有一些重要的设计缺陷或设计问题，立即给出反馈，即使现在还没来得及审核其他部分。实际上，审核其他部分很有可能是浪费时间。只要这个设计问题足够大，在重新设计时，其他代码很有可能会消失或变得无关紧要了。

3.以合适的顺序检查 CL 的其他部分。在确认 CL 没有重要设计问题之后，整理出审视文件的顺序，并确保不会遗漏任何文件。通常，在审视了主要文件之后，最简单的方式就是按照代码审核工具呈现出来的顺序遍历每个文件。有时候，先阅读测试代码更有帮助，因为看了测试代码之后，你就明白这个 CL 的期望行为是什么。

5、代码审核者应该关注哪些？

确保审核了每行代码，并且查看上下文，确保你正在提升代码质量，当开发者的 CL 中包含 好东西 时，称赞他们。

5.1、兼容性

审核者需要判断，本次 CL 是否会影响线上现有功能

1.比如 JSF 接口出参的位置，是否会导致上游调用序列化出错？

2.中间件配置变更，比如数据表增加索引，表数据量多大，会不会增加索引导致数据库阻塞?

3.是否需要增加 Ducc 开关技术，在稳定性和代码复杂性中均衡考量

5.2、设计

1.审核一个 CL 最重要的事情就是考虑它的整体设计，代码是否按照架构设计方案进行编码？

2.API & DataBase 是否合理

3.这段代码应该放到哪里更合适？它是否可以很好地与系统其他部分集成？

4.还应关注：技术栈简单、统一的控制，避免非必要引入三方框架、组件等，为系统稳定性埋下隐患

5.3、功能

1.这个 CL 所实现的功能与需求期望开发的功能是一致的吗？

2.绝大多数情况，我们期望开发者在提交 CL 进行审核之前，已经做过充分的测试。但作为审核者，在审核代码时仍要考虑边界情况、并发问题等等。确保消灭那些通过阅读代码就能发现的缺陷。

3.作为审核者，你可以根据需要亲自验证 CL 的功能。仅通过阅读代码，你很难理解有哪些改变，对系统有哪些影响。对于这种修改，可以让开发者演示这个功能。当然，如果方便把 CL 的代码集成到你的开发环境，你也可以自己亲自尝试。

4.在代码审核过程中，对功能的考虑还包含一种重要场景：CL 中包含一些“并行计算”，可能会带来死锁或竞争条件。运行代码一般很难发现这类问题，通常需要（开发者和审核者）仔细考虑，以确保不会引入新的问题。（这也是不要引入并发模型的一个好理由，因为它可能引入死锁或竞争条件，同时也增加了代码审核和代码理解的难度。）

5.4、性能

1.这段代码如果数据量大，性能是否有问题？有没有更好的实现方式？

案例：多个 for 循环无用业务

5.5、复杂性

1.是不是 CL 可以不必这么复杂？在 CL 的每个层次上检查——哪一行或哪几行是不是太复杂了？功能是否太复杂了？类（class）是否太复杂了？“太复杂”的定义是代码阅读者不易快速理解。 同时意味着以后其他开发者调用或修改它时，很容易引入新的缺陷。

2.另一种类型的复杂是过度工程化（也称为过度设计）。开发者在设计代码时太过于在意它的通用性，或在系统中加入了目前不需要的功能。审核者应该特别警惕过度工程化。鼓励开发者解决 当前 应该解决的问题，而不是开发者推测将来 可能 需要解决的问题。将来的问题，等碰到的时候，你才能看到它的实际需求和具体情况，到那时再解决也不迟。

5.6、日志

日志打印是否简明扼要，是否有助于线上问题排查；关键环节是否打印了日志

5.7、异常

异常处理，是否符合服务可用率治理规范，确保增量代码不腐化已经通过可用率星级认证的接口；

5.8、测试

1.同时要求开发者提供 CL 对应的单元测试。单测代码与开发代码应放到同一个 CL 中，除非碰到紧急情况

2.确保 CL 中的测试是正确的、明智的、有用的。测试代码并不是用来测试其自身，我们很少为测试代码写测试代码——这就要求我们确保测试代码是正确的。

3.当代码出问题时，是否测试会运行失败？如果代码改变了，是否会产生误报？是否每个测试都使用了简单有用的断言？不同的测试方式是否做了合适的拆分？

谨记：测试代码也是需要维护的代码。 不要因为不会编译打包到最终的产品中，就接受复杂的测试代码。

5.9、每行代码

1.在审核代码时，仔细检查每行 代码。某些文件，如数据文件、生成的 set、get 代码或较大的数据结构，可以一扫而过。但是人写的代码，如类、功能或代码块不能一目十行，我们不应假设它是正确的。有些代码得尤其小心——这需要你自己权衡——至少你应该确认你 理解 这些代码在做什么。

2.如果代码很难读懂，那就放慢审核速度，告诉开发者你没读懂代码，让他解释与澄清，之后继续审核。如果你读不懂代码，很有可能其他工程师也不懂。实际上，这么做也是在帮助以后的工程师，当他读到这段代码时更容易理解代码。所以，让开发者解释清楚。

如果你理解这些代码，但是感觉自己不够资格审核它，确保找到一个够资格的人来审核，尤其是比较复杂的问题，如安全、并发、可访问性等等。

5.10、上下文

1.把 CL 放到一个更广的上下文中来看，通常很有用。在审核工具中，我们往往只能看到开发者修改的那部分代码。更多时候从整个文件的角度来读代码才有意义。例如，有时候你只看到添加了几行代码，但从整个文件来看，你发现这几行代码添加到了一个 100 行的方法中。在增加之后，需要把它拆分成更小的方法。

2.把 CL 放到系统的上下文中来考虑也很有用。CL 能提升系统的代码健康状况，还是让系统变得更复杂、更难测试？大多数系统变得很复杂都是由每个细小的复杂累积而成的，在提交每个 CL 时都应避免让代码变得复杂。

5.11、文档

1.如果 CL 修改了编译、测试、交互、发布的方式，那么应检查下相关的文档是否也更新了，如 README 文件、CF 页面，或其他所有生成的参考文档。

2.如果 CL 删除或弃用（deprecate）了一些代码，考虑是否也应删除相应的文档。如果没有这些文档，让开发者（ CL 提交者）提供。

5.12、注释

1.开发者是否写了清晰的注释？是否所有的注释都是必须的？通常当注释解释为什么这些代码应该存在时，它才是必须的，而不是解释这些代码做什么。如果代码逻辑不清晰，让人看不懂，那么应该重写，让它变得更简单。当然，也有例外（例如正则表达式和复杂的算法通常需要注释来说明），但大部分注释应该提供代码本身没有提供的信息，如这么做背后的原因是什么。

2.有时候也应该看一下这个 CL 相关的历史注释。例如，以前写的 TODO，现在可以删掉了；某段代码修改了，其注释也应随之修改。

注意，注释与类、模块、功能的 文档 是不同的，这类文档应该描述代码的功能，怎样被调用，以及被调用时它的行为是什么。

5.13、代码样式

1.在京东，我们所有的主要编程语言都要遵循京东代码规范，确保 CL 遵守代码样式指南中的建议。

2.如果发现某些样式在代码样式指南中并未提及，在注释中加上“Nit”，让开发者知道，这是一个小瑕疵，他可以按照你的建议去做，但这不是必须的。不要因为个人的样式偏好而导致 CL 延迟提交。

3.作者在提交 CL 时，代码中不应包含较大的样式改变。为这样很难比较出 CL 中有哪些代码修改，其后的代码合并、回滚会变得更困难，容易产生问题。如果作者想重新格式化文件，应该把代码格式化作为单独的 CL 先提交，之后再提交包含功能的 CL

5.15、好的方面

如果在 CL 中看到一些比较好的方面，告诉开发者，尤其是当你在审核代码时添加了评论，他在回复你的评论，尝试向你解释的时候。审核者往往只关注代码中的错误，他们也应该对开发者的优秀实践表示鼓励和感谢。有时候，告诉开发者他们在哪些方面做得很好，比告诉他们在哪些方面做得不足更有价值。

6、怎样写代码审核的评论？

1.礼貌，保持友善

2.解释原因：阐明你的意图、你正在遵循的最佳实践、你在提升代码健康程度

3.给出明确的信息，指出问题所在，让开发者最后做决定。

4.鼓励开发者简化代码，给代码添加注释，而不是向你解释为什么这么复杂

7、代码评论被拒绝，应如何处理？

1.开发者和审核者都可能对代码提出修改建议，但应先考虑开发者是否正确。若开发者正确，可忽略评论；否则，审核者需解释建议必要性。

2.若审核者坚持修改，即使需额外工作也值得，因为提升质量是持续过程。

3.有时需多轮解释，保持礼貌。

4.常见拒绝原因是想尽快完成，建议现在就开始清理，或分配给自己 bug 以避免遗忘，加上 TODO 注释和 bug 编号。

四、代码开发者指南

从开发者的角度来看，我们也需要了解一些开发者的指南。这些指南包括：

1.遵循编码规范和最佳实践，编写良好的 CL 描述：作为开发者，我们应该遵循编码规范和最佳实践，确保代码的质量和可读性。

2.CL 提交的原子性，如何定义小 CL？

3.如何处理审核者评论及修改代码？

本文包含开发者怎样让代码审核容易通过的最佳实践。在读完本指南后，相信能够让你的审核质量更高，速度更快。

1、编写良好的 CL 描述

CL 描述内容应该提供足够的信息，让 CR 更加清晰。它包含了改了什么 与 为什么 这么修改？

1.1、良好的 CL 描述

附 Promise 这个 CL，清晰描述了需求 PRD（链接），及核心逻辑，DUCC 开关及单测描述

1.2、糟糕的 CL 描述

“修复 bug”是一个很不恰当的描述。哪个 bug ？你做了哪些事情来修复它？通通都没有。类似糟糕的描述还包括：“增加补丁”，“删除代码”，“没有描述”

2、原子性提交

《持续交付 2.0》的四大工作原则是：坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。这些原则可以不断缩短持续交付“8”字环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。它们在代码提交与 Code Review 中的应用就是：提交的原子性。

2.1、为什么应该写小 CL？

小 CL 有如下优点：

1.评审效率更高： 将大段的 CL 拆分成多个小段 CL。这样可以让评审者更容易集中几分钟（5 分钟比 30 分钟容易）在关键部分，提高评审效率。

2.反馈更及时： 如果开发者花费了很大的精力开发了一个大 CL，直到审核的时候才知道整个开发的方向错了，那么之前的所有时间就全浪费了。

3.引入新缺陷概率更低： 如果修改的内容比较少，自然审核人的效率会更高，开发者与审核者都更容易判断是否引入了新的缺陷。

4.更易于设计： 完善小 CL 的设计和修改要容易得多，多次微小的代码质量提高比一次大的设计改变更容易。

5.更容易合并代码： 大 CL 在合并代码时会花费很长的时间，在合并时需要花费大量时间，而且在写 CL 期间可能不得不频繁地合并。

6.更容易回退：一个大 CL 开发的时间比较长，这意味从开发到代码提交这段期间，代码文件的变更会比较多。当回退代码时，情况会变得很复杂，因为所有中间的 CL 很有可能也需要回退。

请注意：审核者有权因为你的 CL 太大而拒绝它。

2.2、那么如何定义“小”？

一般而言，一个 CL 的大小就应该是 独立功能的修改。这意味着：

1.尽量将一个 CL 的大小最小化，它只做一件事。每个 CL 应该只关注一个特定的功能或任务，而不是整个功能。这样可以使审核者更容易理解和评估 CL 的内容，并减少不必要的复杂性和混乱。可与审核者进行讨论，以确定 CL 的适当大小。可以共同探讨 CL 是否涵盖了足够的功能，并且能够提供足够的上下文来理解 CL 的目的和影响。通过沟通和合作，可以找到最佳的平衡点。

2.确保 CL 中包含了所有必要的信息，以便审核者可以理解 CL 的目的和内容。除了 CL 本身的代码之外，还应包括对 CL 的描述、已存在的代码或之前已经审核过的相关 CL 的信息。这样审核者可以更好地了解 CL 的背景和上下文，从而做出准确的判断。

3.在提交 CL 之后，确保系统仍然能够正常运行。无论是对于用户还是开发人员来说，系统的正常运行是至关重要的。因此，在编写 CL 时，请确保不会引入任何破坏性或不兼容的更改。

4.如果代码难以理解，可能是因为 CL 的大小还不够小。如果需要添加一个新的 API，最好将其与相应的使用方法一起包含在同一个 CL 中。这样可以方便审核者理解如何使用该 API，同时也方便后续的开发者使用和维护。此外，这还可以有效防止提交的 API 无人使用的情况发生。

5.定期回顾和改进您的 CL 过程。通过反思和总结经验教训，您可以找到可能存在的问题和改进的空间。持续优化您的 CL 过程将有助于提高整体的开发效率和代码质量。

没有直观的标准判断 CL “太大”应该符合哪些条件。

2.3、什么时候可以有大 CL？

当然，也有一些例外情形，允许 CL 比较大：

•删除一个文件与修改一行没有太大区别， 因为它不会花费审核者太多时间。

•有时候，一个大 CL 可能是由可靠的自动代码重构工具生成的，审核者的工作主要是检查它是否做了它应该做的工作。虽然符合以上提到的注意事项（例如合并和测试），这类 CL 也可能比较大。

2.4、注意事项

1.CL 之前研发通过插件（idea 集成 JoyCoder，京东 Idea 插件、sonar 等检查语法之类）检查并且修复各种代码样式问题。

2.把系统重构及技术改造的单独 CL

3.把测试代码包含到对应功能的 CL 中

4.不要破坏编译，影响他人

3、如何处理审核者的评论

在发出 CL 之后，审核者一般会给出反馈（评论），让你修改代码。以下是一些建议，可以帮助您在代码审核过程中处理审核者的评论：

3.1、保持好心态

1.先思考自己是否有改进的空间。 仔细考虑审核者是否在反馈中提供了有价值的内容，可以帮助提高代码库的质量。你的第一个问题应该永远都是，“审核者说得对吗？” 如果确认你是对的，那就解释为什么你的方法比较好。

2.保持冷静和专业。无论审核者的评论是正面的还是负面的，都要保持冷静和专业的态度。不要将审核者的评论视为个人攻击或人身攻击，而是将其视为对您工作质量和代码库质量的建议和改进的机会。

3.从建设性的角度去理解评论。审核者可能以批判性的语气表达他们的评论，但作为开发者，您应该努力从中寻找建设性的意见和建议。问问自己，“我能从这个评论中学到什么？如何改进我的代码？”然后根据这些建议来调整和改进您的代码。

4.不要带着情绪回复评论。在代码审核过程中，违反专业礼仪是非常严重的事情。如果您感到生气、恼火或受到冒犯，最好先离开电脑一会儿，或者做其他事情来平静自己的情绪。确保您可以以礼貌和友好的方式回复审核者的评论。

5.尊重审核者的专业知识和经验。审核者通常具有丰富的编程经验和专业知识，他们的意见和反馈对于提高您的代码质量和产品的质量非常重要。尊重他们的专业意见，并尽可能采纳他们的建议进行改进。

6.寻求澄清或进一步解释。如果您对审核者的评论有任何疑问或不理解的地方，不要犹豫向他们寻求澄清或进一步的解释。这有助于消除任何误解，并确保您正确理解了对方的意见和建议。

7.提供适当的回应。在回复审核者的评论时，尽量提供有建设性的回答和解决方案。如果您不同意对方的观点，可以提出您的理由并提出相应的解决方案。避免争论或陷入无意义的争论中。

8.接受批评并持续改进。审核者的评论可能是为了帮助您改进自己的工作和代码库的质量。接受批评，并将其视为一个学习和成长的机会。通过持续改进和修正错误，您可以提升自己的编码能力和产品质量。

3.2、修复代码

1.澄清代码本身。当审核者表示对您的代码中的某些内容不理解时，首先尝试以清晰和简洁的方式澄清代码的目的和功能。确保您能够用简单明了的语言解释代码的逻辑和实现方式。

2.添加注释来解释代码。如果无法通过澄清代码本身来解决审核者的疑问，您可以添加适当的注释来解释为什么这段代码这样写。注释应该简明扼要地概括代码的功能、目的和关键步骤，以便其他开发者能够更好地理解和维护代码。

3.清理和重构。如果审核者无法理解某段代码，很有可能其他的代码阅读者也会遇到相同的困惑。在这种情况下，考虑对代码进行清理和重构，以提高其可读性和可维护性。删除不必要的复杂性，使用清晰的命名约定和适当的代码结构，以帮助其他开发者更容易理解和阅读代码。

4.鼓励开放的沟通和讨论。在处理审核者的不理解时，保持开放和积极的沟通态度非常重要。与审核者一起探讨问题的根源，寻求共同的解决方案，并尽可能提供清晰的解释和支持。这种开放的沟通有助于建立信任和合作，推动问题的解决和改进的进程。

五、代码评审的冲突解决

以下是一些建议，可以帮助您在与审核者之间出现冲突时进行有效的沟通和解决：

1.强调代码的重要性。在与审核者讨论问题时，始终强调代码的重要性和正确性。指出代码是解决问题的关键，而不是个人攻击或人身攻击的借口。

2.尝试达成共识。首先，努力与审核者达成共识并找到双方都可以接受的解决方案。这可能涉及妥协、解释各自的观点和理解对方的立场。通过开放和建设性的讨论，寻找共同的目标和原则。

3.参考代码规范和 CR 标准。如果无法达成共识，可以参考代码规范和 CR 标准等文档来提供指导和准则。这些文档通常包含最佳实践、编码规范和代码审查要求，可以作为解决冲突的参考依据。

4.面对面沟通。当面临无法解决的问题时，考虑面对面与审核者进行沟通。面对面的会议可以提供更多的上下文和细节，有助于更好地理解彼此的观点，并更有效地解决问题。确保在会议之后记录下讨论的结果，并在代码审核评论中进行反馈。

5.寻求团队的支持和意见。如果面对面的沟通仍然无法解决问题，可以寻求其他团队成员（如架构师、TL）的意见和支持。他们可能能够提供不同的视角和解决方案，帮助您更好地处理冲突。让 TL 参与讨论并做出最终决定，以确保问题得到适当的解决和跟进。

6.保持专业和尊重的态度。无论遇到什么情况，都要保持专业和尊重的态度对待审核者和整个团队。避免争吵、指责或情绪化的反应，而是以理性和冷静的方式处理冲突，并致力于找到最佳的解决方案。

六、紧急情况

以下是一些建议，可以帮助您处理紧急的 CL 和相关的代码审核流程：

1.快速响应并加快审核流程。在紧急情况下，审核者应该优先考虑代码的正确性和解决紧急问题的能力，尽快回复审核者的请求，并尽力加快审核流程。这可能包括加快代码评审、测试和验证的速度，以及与团队成员协调解决问题的时间。

2.完成紧急情况后进行更全面的审核。一旦紧急情况处理完毕，您可以回过头来进行一次更全面的代码审核。这次审核可以检查代码的整体质量和一致性，并确保所有的功能和修复都按照最佳实践进行编写和维护。

3.记录和总结经验教训。紧急情况发生后，及时记录下您的处理过程和经验教训。回顾这些经验可以帮助您改进未来的应对策略，并为类似的情况提供参考依据。

七、CodeReview-AI 大模型

1.上面描写的都是人去 CodeReview，但靠人力太费事费力，而且团队每个人的水平不一样，这样也会导致 CR 的效果也不一样。所以我们需要思考如何利用科技的力量，比如大模型等工具去 CodeReview，通过定义好的代码规范和代码比对，给出建议等，提升代码效率的同时也保障了代码质量。

八、总结

总之，在进行代码评审时，我们需要从评审者和开发者的不同角度出发，关注不同的方面。通过合理的评审和开发指南，提高代码质量和团队协作效率。上面描述的方式还需要大家在实践过程中进行持续改进，并根据团队的实际情况进行调整：

1.考虑团队的特点和需求。每个团队都有自己独特的特点和需求。在制定代码审查方法和流程时，要充分考虑团队的规模、项目类型、开发语言和技术栈等因素。确保所选的方法和流程与团队的实际情况相适应。

2.定期回顾和改进。代码审查是一个持续不断的过程，需要定期回顾和改进。定期与团队成员讨论和评估当前的代码审查方法和流程，了解他们的体验和意见。根据反馈和经验教训进行必要的调整和改进。

3.培养学习氛围和文化。代码审查不仅是为了解决问题和提升代码质量，也是一个学习和成长的机会。鼓励团队成员互相支持、分享知识和经验，并建立一种积极进取的学习文化。通过培训、分享会和团队活动等方式来促进学习和知识传递。

4.保持持续改进的动力。代码审查是一个长期而持续的过程，需要不断努力和改进。保持对代码质量的关注和追求卓越的动力，将代码审查视为一个持续改进的机会，并不断寻求提高团队整体代码水平的方法。

本文旨在为大家提供参考和借鉴。同时也欢迎大家对文章进行指正和建议，以便更好地完善我们的实践经验。如果您有更好的实践经验，也欢迎与我们交流分享。谢谢！

参考文献：

Google Engineering Practices Documentation

谷歌代码审查指南 译文：https://jimmysong.io/eng-practices/docs/review/