本節書摘來自華章出版社《effective debugging：軟體和系統調試的66個有效方法》一書中的第1章，第1.1節，作［希］迪歐米迪斯·斯賓奈裡斯（diomidis spinellis），更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視
請想象這樣一種場景：george在電話裡朝你大吼，說你開發的那個應用程式“運作不了”，于是你趕緊把問題寫在便簽上，然後把它貼在顯示器旁邊，顯示器周圍還有很多類似的紙條。現在你開始回想，自己到底有沒有把新版程式所需的最新庫檔案發給george。實際上，我們不應該這樣來處理問題，而是應該改用下面的辦法。
首先，要保證有一套事務追蹤系統（issue-tracking system）可供使用。很多開源軟體庫，如github和gitlab等，都提供基本的事務追蹤系統，該系統與它們所提供的其他功能是內建在一起的。有些組織使用一種名為jira的專有系統，這種系統要複雜得多，它可以在企業内部運作，也可以作為服務來運作。還有一些組織使用開源替代品，如bugzilla、launchpad、otrs、redmine或者trac。選擇哪個系統并不重要，重要的是必須保證所有的事務都記錄在這個系統裡面。
如果某個問題沒有記錄在事務追蹤系統中，那我們就拒絕處理該問題。堅持使用這樣的系統，能夠帶來下面幾個好處：
可以看見調試工作所取得的進展。
可以對軟體的發行進行追蹤與規劃。
幫助我們确定各種工作項（work item）之間的優先次序。
幫助我們把常見的事務及其解決方案整理成文檔。
防止我們遺漏某些問題。
可以自動生成發行說明（release note）。
可以用作知識庫，使我們對軟體中的缺陷進行估量及反思，并從中總結經驗。
對于公司裡面那些不必親自彙報問題的高層員工來說，你可以代他們彙報問題。如果某個問題是你自己發現的，那你也可以自己把這個問題送出到系統裡面。有一些公司規定：在修改代碼之前，必須先指明這次修改所涉及的事務。
我們還要保證的是：每一項事務都能夠精确地描述問題的重制方式。最好能在其中給出一個簡短（short）、自足（self-contained）且正确（correct，也就是可以正确編譯并運作）的例子（example），即sscce。我們可以把這個例子直接剪下來，粘貼到應用程式中，以便重制它所要說明的問題（參見第10條）。為了使大家能夠寫出有效的錯誤報告（bug report），我們應該制訂一份規範，并勸說所有人都認真遵照這份規範來撰寫報告。（我看到有一家公司把這些規範貼在廁所門上。）
此外，錯誤報告還必須具備精确的标題（precise title），并寫明bug的優先級（priority）、嚴重程度（severity）、受影響的利益相關者（stakeholder），以及該bug的發生情境（environment）。在填寫這些内容時，要注意以下幾點：
精準的标題使我們能夠在事務彙總報告中迅速找出這個bug。用“程式崩潰”這幾個字做标題是很糟糕的，應該改成“正在儲存時單擊重新整理按鈕，會使程式崩潰”。
嚴重程度能夠幫助我們判斷bug的優先級。與資料丢失有關的問題當然是很嚴重的，而另外一些無關緊要的問題，或是可以用某種明确的方式來繞過的問題，則顯得不那麼嚴重。團隊可以根據bug的嚴重程度來對清單裡面的各項事務進行分類，以決定哪些事務需要立刻解決，哪些可以稍後解決，哪些應該忽略。
對事務進行分類并排定其次序之後，就可以把結果填寫在優先級這一欄中了，這使得我們能夠據此安排各項事務的處理順序（參見第8條）。在很多項目中，bug的優先級是由開發者或項目主管來設定的，如果允許終端使用者來設定，那麼他們總是會把自己送出的所有bug都設定成最高優先級。雖說管理人員、客戶代表、其他團隊的開發者以及銷售人員都宣稱自己送出的事務應該最先得到處理，但我們還是應該根據實際情況來設定優先級。
在事務中指出受到影響的利益相關者，可以幫助團隊獲知與該事務有關的其他一些資訊，并幫助産品擁有者來決定事務的優先次序。有些公司甚至會在利益相關者後面标注他們給公司帶來的年度收入。（例如，“由acme所送出，該客戶給公司帶來的年度收入是25萬元。”）
對于某些難以捕獲的bug來說，情境描述可以提供線索，使得我們能夠重制這種bug。不要強迫使用者填寫過多的資訊，例如，pc的序列号、bios的日期，以及系統中每一個程式庫的版本等，這樣做會令使用者覺得非常麻煩，進而跳過這些内容。我們隻應該詢問與bug密切相關的那些細節，對于web應用程式來說，浏覽器的資訊自然是相當重要的，而對于移動應用程式來說，我們或許想知道裝置的制造商及型号。如果能夠通過軟體來自動送出這些資訊，那就更好了。
使用事務追蹤系統時，我們一定要通過它來記錄進度。大部分追蹤系統都允許使用者在每個事務後面持續追加各種形式的評論。這些文檔可以把調查及修複bug時所經曆的步驟記錄下來，其中也可以包括修複bug時所遇到的困境。這樣做可以使公司内的工作更加透明。我們應該精确地寫出記錄或追蹤程式行為時所執行的各種指令，這樣做很有用，因為明天你可能就要重新執行這些指令，你或你的同僚也有可能要在一年之後尋找一個類似的bug。當你辛苦地完成了為期一周的bug搜尋工作之後，這些筆記可以幫助你回顧工作内容，使你能夠更好地把這些天所做的事情解釋給團隊或管理者聽。
要點
通過事務追蹤系統來處理所有的問題。
確定每項事務都能夠以短小、自足而又正确的範例（sscce），精确地描述出該問題的重制方式。
對事務進行分類，并根據每項事務的優先級與嚴重程度來安排工作。
通過事務追蹤系統來記錄進度。