Matt Doar

Bug 無所不在#

不論你稱它們為 bugs、defects，還是 design side effects，你都無法逃避它們。學會如何提交好的 bug 報告，以及如何在 bug 報告中尋找關鍵資訊，是讓專案順利推進的重要技能。

好的 Bug 報告#

一份好的 bug 報告需要傳達三件事：

• 如何重現 bug：盡可能精確描述，包括這個 bug 多常出現
• 預期應該發生什麼：至少是你認為應該發生的行為
• 實際發生了什麼：盡可能多地記錄實際結果

Bug 報告中的資訊量與品質，既反映了 bug 本身，也反映了回報者。憤怒、簡短的 bug（例如「這個功能爛透了！」）只能告訴開發者你心情不好，除此之外沒什麼幫助。提供充足上下文、便於重現的 bug 報告，會贏得所有人的尊重。

Bug 狀態的管理#

改變 bug 的狀態——例如從 Open 改為 Closed——是對你對這個 bug 看法的公開聲明：

• 花時間解釋為什麼你認為 bug 應該關閉，可以省去日後向挫折的經理和客戶證明合理性的時間
• 改變 bug 的**優先級（priority）**也是類似的公開聲明——不要因為某個 bug 對你來說微不足道，就認為它不會阻礙其他人使用產品

不要濫用欄位#

不要為了個人目的而超載 bug 的欄位。例如在 subject 欄位加上「VITAL:」前綴，可能讓你更容易排序報告結果，但這種做法最終會被其他人複製並不可避免地打錯字。應該使用新的值或新的欄位，並記錄這個欄位的用法，讓其他人不必重蹈覆轍。

團隊協作#

• 確保每個人都知道如何找到團隊正在處理的 bug——通常可以透過一個有明確名稱的**公開查詢（public query）**來完成
• 確保大家使用相同的查詢，不要在未先通知團隊的情況下更改查詢條件

Bug 不是標準的工作單位，就像一行程式碼不是精確的工作量衡量指標一樣。Bug 就像一場對話，所有的歷史記錄都攤在每個人面前。不要責怪他人或否認 bug 的存在——而是詢問更多資訊，或反思自己可能遺漏了什麼。