代码审查

审查 pull request 是一种常见的贡献类型。尽管持续集成（CI）确保代码做了应该做的事，但这还不够。有一些贡献特征是无法自动化的：设计、代码结构与架构、测试质量或拼写错误。以下各节代表代码审查过程的不同方面。

可读性

代码是否清楚地表达了它的意图？如果你需要花费大量时间来弄清楚代码的作用，则代码实现需要改进。 建议将代码拆分为更小、更容易理解的抽象。或者作为最后手段，可以添加注释解释其背后的推理。问问你自己，如果没有 pull request 描述等周围上下文，你是否能够在不久的将来理解这段代码。

小型 pull request

大型 pull request 很难审查，容易遗漏细节。如果一个 pull request 变得太大而难以管理，建议作者将其拆分。

一致性

变更与项目的其余部分保持一致非常重要。不一致会使维护复杂化，因此我们应该避免它们。如果有一种向用户输出消息或报告错误的方法，我们应该坚持使用。如果作者不同意项目的标准，建议他们开一个 issue，我们可以在那里进一步讨论。

测试

测试允许有信心地更改代码。Pull request 中的代码应该被测试，且所有测试都应该通过。一个好的测试是一个能始终产生相同结果且易于理解和维护的测试。审查者的大部分审查时间花在实现代码上，但测试同样重要，因为测试也是代码。

破坏性变更

破坏性变更对 Tuist 用户来说是一种糟糕的用户体验。贡献应该避免引入破坏性变更，除非绝对必要。有很多语言特性我们可以利用来演进 Tuist 的接口而不必诉诸破坏性变更。某个变更是否是破坏性的可能并不明显。验证变更是否具有破坏性的方法是对着 fixtures 目录中的 fixture 项目运行 Tuist。它需要我们站在用户的角度，想象变更会如何影响他们。