# 代码审查 {#code-reviews}

审查拉取请求是一种常见的贡献方式。尽管持续集成 (CI) 能确保代码按预期运行，但这还不够。有些贡献特质无法自动化：设计、代码结构与架构、测试质量或拼写错误。以下部分代表了代码审查流程的不同方面。

## 可读性 {#readability}

代码是否清晰地表达了其意图？**如果你需要花费大量时间来弄清楚代码的作用，那么代码实现就需要改进。** 建议将代码拆分为更小的、更容易理解的抽象单元。或者，作为最后的手段，可以添加注释来解释其背后的逻辑。问问自己，在没有拉取请求描述等周围上下文的情况下，你是否能在不久的将来理解这段代码。

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

大型拉取请求难以审查，容易遗漏细节。如果拉取请求变得过大且难以管理，建议作者将其拆分。

> [!NOTE]
> **例外情况**
>
> 在少数情况下，无法拆分拉取请求，例如当更改紧密耦合且无法拆分时。在这些情况下，作者应提供清晰的更改说明及其背后的理由。


## 一致性 {#consistency}

重要的是，更改应与项目的其余部分保持一致。不一致会增加维护的复杂性，因此我们应该避免这种情况。如果有向用户输出消息或报告错误的方法，我们应该坚持使用该方法。如果作者不同意项目的标准，建议他们创建一个议题，以便我们进一步讨论。

## 测试 {#tests}

测试让我们能够自信地更改代码。拉取请求中的代码应该经过测试，并且所有测试都应该通过。好的测试是能够始终产生相同结果、易于理解和维护的测试。审查者大部分时间都花在实现代码上，但测试同样重要，因为它们也是代码。

## 破坏性变更 {#breaking-changes}

破坏性变更会给 Tuist 用户带来糟糕的体验。除非绝对必要，否则贡献应避免引入破坏性变更。我们可以利用许多语言特性来演进 Tuist 的接口，而无需进行破坏性变更。变更是否具有破坏性可能并不明显。验证变更是否具有破坏性的一种方法是在 fixtures 目录中的示例项目上运行 Tuist。这需要我们要站在用户的角度，想象这些变更会如何影响他们。