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

審查拉取請求係一種常見嘅貢獻方式。雖然持續整合 (CI) 可以確保程式碼執行預期功能，但並不足夠。有些貢獻特質無法自動化：設計、程式碼結構與架構、測試品質，或者錯別字。以下章節代表程式碼審查流程嘅唔同面向。

## 可讀性 {#readability}

程式碼會唔會清晰表達其意圖？**如果你需要花大量時間先至搞清楚程式碼做緊乜，就表示程式碼實作需要改進。** 建議將程式碼拆分為較小、更易理解嘅抽象層。作為最後手段，亦可以加入註解解釋背後嘅理據。問下自己，如果冇拉取請求描述等周邊脈絡，你喺不久將來仲可唔可以理解呢段程式碼。

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

大型拉取請求難以審查，亦容易忽略細節。如果拉取請求變得太大而難以管理，建議作者將其拆分。

> [!NOTE]
> **例外情況**
>
> 有少數情況無法拆分拉取請求，例如當變更緊密耦合而無法分割。在這些情況下，作者應該提供清晰嘅變更說明及其背後理據。


## 一致性 {#consistency}

變更必須與專案其餘部分保持一致。不一致會令維護變得複雜，因此我哋應該避免。如果有既定方式向用戶輸出訊息或報告錯誤，我哋應該遵循。如果作者不同意專案標準，建議佢開立一個議題以便進一步討論。

## 測試 {#tests}

測試讓你可以有信心地更改程式碼。拉取請求中嘅程式碼應該經過測試，而且所有測試都應該通過。好嘅測試係指能夠一致產生相同結果，並且易於理解同維護嘅測試。審查者大部分時間都花喺實作程式碼上，但測試同樣重要，因為佢哋都係程式碼。

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

破壞性變更會對 Tuist 用戶造成不良體驗。除非絕對必要，否則貢獻應該避免引入破壞性變更。我哋可以利用許多語言特性來演化 Tuist 介面，而無須進行破壞性變更。一項變更是咪屬於破壞性變更可能並不明顯。驗證變更是咪具有破壞性嘅方法之一，係喺 fixtures 目錄中針對範例專案執行 Tuist。這需要我哋換位思考，想像變更會點樣影響用戶。