一份程式變更可能語法正確，卻不適合這個專案。它可能重複既有的輔助函式、忽略錯誤處理慣例，或在錯誤的層級解決問題。這些通常源自對脈絡理解不足。
找出行為界線
先找出任務要改變的行為。以搜尋錯誤為例，可能涉及輸入處理函式、請求函式與畫面狀態，不一定包含所有名稱帶有「search」的檔案。
接著閱讀相關測試。測試常記錄實作中不易看出的預期行為，例如空白查詢應立即清除結果，或較舊的回應不得覆蓋較新的結果。
整理工作所需的資料
有用的工作資料包含現有實作、具代表性的慣例，以及定義成功條件的檢查。範圍應精簡到能夠說明清楚；毫無選擇地增加脈絡，可能反而掩蓋相關限制。
當慣例橫跨多個檔案時，專案指示就能派上用場。「使用既有的請求驗證輔助函式」這類簡短規則，能給代理具體方向；再指出函式位置，就能提供實際範例。
讓假設可供檢視
編輯前，先請代理簡短說明目前行為與建議變更。如此便有機會在錯誤前提擴散到多個檔案前及時修正。
能讓你發現並修正問題的計畫，才有價值。
計畫不必寫成長篇文件。對範圍明確的變更，三個步驟加上一項明確假設可能就足夠。關鍵是其他人能否理解代理為何選擇這個做法。
回到最初的構想
完成程式變更後，請對照原始需求，同時檢查期望改變與應維持穩定的行為。脈絡既是任務的輸入，也是審查成果的標準。
繼續閱讀