程式碼審查

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

可讀性#

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

小型拉取請求#

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

一致性#

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

測試#

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

破壞性變更#

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