前言

本文参考《京东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/