# 代码审查 {#code-reviews}

审核拉取请求是一种常见的贡献类型。尽管持续集成（CI）确保了代码的正常运行，但这还不够。有些贡献特征是无法自动化的：设计、代码结构和架构、测试质量或错别字。以下章节介绍了代码审查流程的不同方面。

## 可读性 {#readability}

代码是否清楚地表达了其意图？**如果您需要花费大量时间来弄清代码的作用，那么代码的实现就需要改进。**
建议将代码拆分成更容易理解的小抽象。另外，作为最后的资源，他们可以添加注释，解释背后的原因。扪心自问，如果没有拉取请求描述这样的上下文，你是否能在不久的将来理解代码。

## 小型拉取请求 {#small-pull-requests}

大的拉取请求很难审核，容易遗漏细节。如果拉取请求变得过于庞大，难以管理，建议作者将其分解。

信息例外
<!-- -->
在少数情况下，拉取请求是不可能拆分的，比如当变更是紧密耦合的，无法拆分。在这种情况下，作者应清楚地解释更改及其背后的原因。
<!-- -->
:::

## 一致性 {#consistency}

重要的是，更改要与项目的其他部分保持一致。不一致会使维护工作复杂化，因此我们应该避免。如果有向用户输出信息或报告错误的方法，我们就应该坚持。如果作者不同意项目的标准，建议他们打开一个问题，我们可以进一步讨论。

## 测试 {#tests}

通过测试，可以放心地修改代码。拉取请求中的代码应经过测试，且所有测试都应通过。一个好的测试应能持续产生相同的结果，并且易于理解和维护。审核人员的大部分审核时间都花在了代码实现上，但测试也同样重要，因为它们也是代码。

## 突破性变化 {#Breaking-changes}

对 Tuist 用户来说，破坏性更改会带来糟糕的用户体验。除非绝对必要，否则应避免引入破坏性更改。我们可以利用许多语言特性来改进 Tuist
的界面，而无需进行破坏性修改。一项改动是否具有破坏性可能并不明显。一种验证变更是否破坏性的方法是针对 fixtures 目录中的灯具项目运行
Tuist。这需要我们设身处地地为用户着想，想象这些更改会对他们产生怎样的影响。