透過審查，產生的程式碼才能成為有人願意負責的變更。如果變更難以檢視，撰寫時省下的時間，可能又得花在理解它上面。
選定一個變更理由
連貫的程式差異，有清楚的存在理由。錯誤修正可以搭配回歸測試與小幅文件更正，只要它們服務同一個目的。大規模格式整理，通常會讓行為變更更難辨識。
在任務開始時說明界線，列出成果、相關元件，以及應維持穩定的部分。這些限制能幫助代理判斷，順手的改進是否該納入此次變更。
讓測試承載行為
有用的回歸測試，應在原始錯誤存在時失敗，並在預期修正後通過。它應描述呼叫端或使用者在意的行為，而非重演新實作的內部步驟。
以搜尋防抖為例，應測試快速輸入、取消工作與空白結果。只檢查計時器是否存在，較難說明功能是否正確。
撰寫可用的交付說明
精簡的交付說明會解釋改了什麼、為什麼改，以及如何檢查，也會列出限制。若未驗證瀏覽器互動，就應明確說明，避免讓單元測試結果被誤認為涵蓋更多範圍。
摘要應引導讀者找到證據。
讓最終決策保持明確
代理可以準備程式變更並蒐集證據，維護者仍需判斷成果是否適合專案。範圍精簡、測試有意義、未知之處說明清楚時，這項決策就會更容易。
良好的審查習慣，是讓快速草稿成為可靠貢獻的關鍵機制。
繼續閱讀