為什麼需要 Issue-Tracking System#
當同事打電話抱怨程式壞了，你在便利貼上記下問題然後貼在螢幕旁邊——這不是正確的做法。你需要一套 issue-tracking system 來管理所有問題。
常見的系統包括 GitHub Issues、GitLab、JIRA、Bugzilla、Redmine、Trac 等。選用哪一套不是重點，重點是把所有問題都記錄在裡面。
拒絕處理任何沒有被記錄在 issue-tracking system 中的問題。
使用 Issue-Tracking System 的好處#
- 讓除錯工作具有可見性 (visibility)
- 支援 release 的追蹤與規劃
- 方便工作項目的優先排序
- 幫助記錄常見問題與解決方案
- 確保沒有問題被遺漏
- 自動產生 release notes
- 作為缺陷的歷史資料庫，用於度量、反思與學習
撰寫良好的 Bug Report#
每個 issue 都應包含精確的重現方式 (how to reproduce)。理想的做法是提供一個 SSCCE (Short, Self-Contained, Correct Example)，讓人可以直接複製貼上就能看到問題。
一份好的 bug report 還需要：
- 精確的標題：「Program crashes」是糟糕的標題；「Crash when clicking on Refresh while saving」才是好的
- 嚴重程度 (severity)：幫助團隊做 triage，決定先處理哪些問題
- 優先順序 (priority)：經過 triage 後設定的處理順序，通常由開發者或專案負責人決定，而非終端使用者
- 利害關係人 (stakeholders)：幫助產品負責人取得額外資訊並排定優先順序
- 環境描述 (environment)：只要求最相關的細節，例如 web app 要記錄瀏覽器，mobile app 則記錄裝置型號
考慮將環境資訊的收集自動化，嵌入到軟體本身，減輕使用者負擔。
記錄你的除錯進度#
善用 issue-tracking system 來記錄你的進度。在每個 issue 底下追加留言，記錄你調查和修復 bug 的步驟，包括走過的死胡同。這些記錄：
- 讓組織的運作更透明
- 在你隔天需要繼續時非常有用
- 當未來遇到類似 bug 時可以參考
- 在向主管報告工作成果時能幫助你回憶
重點回顧#
- 透過 issue-tracking system 處理所有問題
- 確保每個 issue 包含精確的重現描述，附上簡短、自足、正確的範例
- 根據每個 issue 的 priority 和 severity 來做 triage 並安排工作
- 透過 issue-tracking system 記錄你的除錯進度