第352期：Bug 追蹤系統的正確樣子

上週的話題是 GitHub Issues，把它當作筆記工具，很強悍。但是，有些話來不及說。它的本職工作——Bug 追蹤系統——並不好用。你用它來管理 Bug，就會發現有設計缺陷，用起來不順手。現在還活着的、歷史最悠久的 Bug 追蹤系統是 Bugzilla。它的一個早期工程師，前不久寫了一篇文章，介紹 Bugzilla 的四條設計原則。

他說，只有滿足這四點，纔是一個好的 Bug 追蹤系統（bug tracking system），我感到很有啓發。（1）所有任務都要列入 Bug 追蹤。不僅包括代碼 Bug，還包括待開發的新功能、缺失的文檔、令人困惑的用戶體驗、糟糕的性能等等。換言之，Bug 追蹤系統本質是任務管理，應該當作項目管理系統來用。（2）Bug 的狀態有多種，不只“打開”和“關閉”兩種。

大公司的 Bug 處理流程，可能很複雜，下面是一張從 Bugzilla 文檔拷貝的流程圖。Bug 追蹤系統應該足夠靈活，可以自定義優先級、嚴重程度、是否已分配、是否有依賴等等，以便適配各種流程。（3）每個 Bug 只能由一人負責。這樣才能明確責任，方便查看每個人正在做什麼、接下來要做什麼、以及最近做了什麼。這也有利於培養開發者的歸屬感和成就感。（4）支持自定義視圖。

由於 Bug 有多種狀態，追蹤系統必須支持自定義視圖查看，擁有強大的查詢功能。系統的默認視圖：按照優先級，列出當前版本的所有沒有關閉的 Bug。開發者的個人視圖：列出分配給他們的所有 Bug，同樣按優先級排序。另外，用戶可以保存自己的自定義視圖。以上四條，就是好的 Bug 追蹤系統的標準。問題是 GitHub Issues 一條都沒做到。1. 項目管理功能太弱。1. 狀態只能靠標籤。1. 任務可以分配給多個人。

1. 視圖默認按創建時間排序，且只能切換成標籤視圖。在這方面，GitHub 甚至不如 Gitea。舉例來說，GitHub 沒有辦法讓最重要的 Bug（P0 級別），自動出現在第一位（下圖），除非手動置頂。相比之下，Gitea（包括分叉的 Forgejo）提供了“標籤集”（label set），允許一個標籤有多個值，並可以按同一個標籤的值排序。

上圖中，標籤“Priority”（優先級）有多個值，然後系統允許按照 Priority 的值排序。

來源｜阮一峯科技愛好者週刊第 352 期，