我把修好的 bug 又回報修了 16 次

11 月 3 日，我打開 16 張工單，卻沒有東西可以修

先從那天日記裡寫的數字說起。確認錯誤工單後關閉的 PR 有 16 個，全部都是「已經在 main 修好」。用標題算出來的有 13 個，剩下 3 個的寫法不一樣。

Dongne Bakery 的「異常結束」（#5259）、汗蒸幕的「在上一個畫面沒有任何訊號就關掉」（#5263）、Teolmungchi 的「異常結束」（#5287）、Wakppu Tower 的手機錯誤 3 件（#5307）就是例子。打開一看結論都一樣：修好的 commit 早就在 main 裡，程式碼這邊沒有事可做。

確認一張工單要花時間：找出錯誤指紋、看是哪個版本發生的、找到修好的 commit 再連起來。程式碼一行都沒變，這些時間卻花了 16 次。

送出錯誤的是修好之前的 App

原因不是錯誤新發生，而是舊版 App 一直在送。沒有在應用程式商店更新的人，用的還是修好之前的版本。那個 App 一當掉，在收集器裡就會變成一筆新的錯誤。

#5276 只有 Wakppu Tower 1.0.17 送出，#5275 只有麵包合成遊戲 1.0.3 送出。#5258 在 1.0.4 以上的版本沒有再發生，是 0 件。這些數字說的是「修好之後的版本不會當機」。但收集器不管版本號碼，同一個錯誤就當成同一個錯誤來算。

一個錯誤判斷：以為有錯誤進來就是新 bug

做收集器的時候，我假設「收到一筆錯誤，就代表現在多了一個要修的 bug」。這個假設只看錯誤進來的順序，沒有問那個錯誤是哪個時間點的程式碼發生的。

我修得很快，但大家更新的速度沒那麼快。修好的 bug 越多，「已經修好的 bug」從舊版本再次進來的路也跟著變多。

那天日記「今天的浪費」的第二行就是這 16 件。每一件都花了一個 PR，改掉的程式碼卻是 0。

修好之後，十天內同樣的 PR 又多了 29 個

我在明天的待辦寫了「舊版本的錯誤不開工單，只寫進帳本。版本號碼比 main 低就過濾掉，先從收集器做起」（t-261103-bszc）。

之後到 11 月 11 日為止，數標題裡有「已經修好」的錯誤 PR，從 11 月 1 日起共 42 件。扣掉 11 月 3 日的 13 件，之後 8 天是 29 件。每天平均從 13 件降到 3 到 4 件，但不是 0。

#6070 麵包合成遊戲 1.0.3、#6377 網咖遊戲 2.0.37、#6473 Algoitneun Yeou 1.0.6 就是例子。修好的版本推出後，舊版本還會活很久。這個數字是數 PR 標題得來的，所以標題寫法不同的案例沒有算進去。

所以我改了什麼

錯誤進來時，先看兩件事再看數量：送出的 App 版本號碼，以及修好那個錯誤的 commit 所在的第一個版本。送出的版本比修好的版本低，就不是新 bug，而是舊版本的回報。

我也增加了把修好的 commit 號碼用一行記進錯誤帳本的做法。這樣同樣的指紋再進來時，帳本馬上就會顯示「已經修好、哪個 commit、從哪個版本開始」。工單那邊則改成以 commit 為單位記錄標籤（#5316）。

處境一樣的話，先試試這幾件事

如果你是自己接上當機監控的獨立開發者，這個順序可以幫你省時間。工具名稱不同，但大部分都有 App 版本篩選。

還有一件事沒做完。版本號碼偏低的錯誤，在開成工單之前自動過濾到什麼程度，我寫這篇時沒有再用程式碼確認。可以確定的是，將近十天過去的現在，還是有要打開確認再關掉的 PR。

• 計算錯誤數量之前，先依 App 版本分開看
• 把修好的 commit 所在的第一個版本號碼寫進帳本
• 送出的版本比那個低，就不開工單，只寫進帳本
• 確認舊版本減少的速度，判斷需不需要強制更新