# 程式碼審查 {#code-reviews}

審查拉取請求是一種常見的貢獻方式。儘管持續整合（CI）能確保程式碼執行預期行為，但這還不夠。有些貢獻特質無法自動化：設計、程式碼結構與架構、測試品質，或拼寫錯誤。以下章節代表程式碼審查流程的不同面向。

## 可讀性 {#readability}

程式碼是否清楚表達其意圖？**如果你需要花很多時間才能弄清楚程式碼在做什麼，就表示實作需要改進。** 建議將程式碼拆分為較小且更容易理解的抽象單元。作為最後手段，也可以新增註解來說明背後的理由。問問自己：在沒有拉取請求描述等周邊脈絡的情況下，未來是否仍能理解這段程式碼。

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

大型拉取請求難以審查，也更容易遺漏細節。如果拉取請求變得過於龐大且難以管理，建議作者將其拆分。

> [!NOTE]
> **例外情況**
>
> 在某些情況下無法拆分拉取請求，例如變更緊密耦合而無法分割。在這些情況下，作者應提供清晰的變更說明及其背後的原因。


## 一致性 {#consistency}

變更應與專案的其他部分保持一致。不一致會增加維護難度，因此我們應避免這種情況。如果專案已有向使用者輸出訊息或回報錯誤的方式，我們應遵循該做法。如果作者不同意專案標準，建議他們開啟一個議題，以便進一步討論。

## 測試 {#tests}

測試讓我們能有信心地變更程式碼。拉取請求中的程式碼應經過測試，且所有測試都應通過。好的測試能穩定產生相同結果，且易於理解與維護。審查者大多將時間花在實作程式碼上，但測試同樣重要，因為它們也是程式碼。

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

破壞性變更會對 Tuist 使用者造成不良的使用者體驗。除非絕對必要，否則貢獻應避免引入破壞性變更。我們可以運用許多語言特性來演進 Tuist 的介面，而不必訴諸破壞性變更。一項變更是否具有破壞性可能並不明顯。驗證變更是否具破壞性的方法之一，是在 fixtures 目錄中對範例專案執行 Tuist。這需要我們站在使用者的角度，想像這些變更會對他們造成什麼影響。