# 代碼檢閱{#code-reviews}

審查 pull request 是一種常見的貢獻方式。儘管持續整合 (CI)
可確保程式碼達到預期的效果，但這還不夠。有些貢獻的特質是無法自動化的：設計、程式碼結構與架構、測試品質或錯誤。以下各節代表程式碼檢閱流程的不同面向。

## 可讀性{#readability}

程式碼是否清楚地表達了它的意圖？**如果您需要花一大堆時間來搞清楚程式碼的作用，那麼程式碼的實作就需要改進。**
建議將代碼分割成更容易理解的小抽象。另類的，也是最後的資源，他們可以加上註解解釋背後的理由。問問自己，如果沒有拉取請求描述等任何周圍的上下文，你是否能夠在不久的將來理解這段程式碼。

## 小的拉取請求{#small-pull-requests}

大的拉取請求很難審閱，也很容易遺漏細節。如果拉取請求變得太大且無法管理，建議作者將其分解。

> [!NOTE]
> **Exceptions**
>
> 有幾種情況是不可能分割 pull request 的，例如當變更是緊耦合的，無法分割。在這種情況下，作者應該提供清楚的變更解釋及其背後的原因。


## 一致性{#consistency}

變更與專案的其他部分保持一致是很重要的。不一致會讓維護工作變得複雜，因此我們應該避免。如果有向使用者輸出訊息或報告錯誤的方法，我們應該堅持。如果作者不同意專案的標準，建議他們開啟一個問題，讓我們可以進一步討論。

## 測試{#tests}

透過測試可以放心地變更程式碼。拉取請求上的程式碼應該經過測試，而且所有的測試都應該通過。一個好的測試是能持續產生相同的結果，而且容易理解和維護。審查員大部分的審查時間都花在實作程式碼上，但測試也同樣重要，因為它們也是程式碼。

## 突破性變更{#breaking-changes}

對 Tuist 使用者而言，破壞性變更會造成不良的使用者經驗。除非絕對必要，否則應該避免引入破壞性變更。我們可以利用許多語言特性來發展 Tuist
的介面，而無需進行破壞性變更。一項變更是否會造成破壞可能並不顯著。驗證變更是否破壞的一種方法是針對 fixtures 目錄中的 fixture 專案執行
Tuist。這需要站在使用者的立場，想像這些變更會如何影響使用者。