BUG平臺應該是一個知識庫
我很喜歡看各個產品的Bug追蹤系統，比如jQuery的Bug Tracker，因為在Bug系統中總能發現一些非常細節的問題，補充自己的知識，慢慢地自己的代碼的兼容性會有很大的提高。
但是，在各個Bug系統之中，包括現在公司使用的Trace系統，無一例外地存在一些讓我不滿意之處，其中最大的原因就是很多Bug系統僅僅是作為Bug的記錄系統存在，而沒有試圖去讓一個Bug成為一個知識的積累，讓整個Bug系統變成一個豐富充實的知識庫。這樣的Bug系統，永遠都只是提供一個簡單的業務流程，不會變成干完人員、產品、甚至是整個團隊的進步的天梯。
在我看來，一個Bug系統應該更加全面，管理Bug的生命周期的同時，也用于管理一個產品、團隊的知識，更可以與周邊系統合作，形成一個真正的集成式管理平臺。
Bug的分類
現在的Bug系統，對Bug系統的分類通常有這么幾種：
- 根據性質：Bug、Feature、Enhancement等。
- 根據危險程度：Trival、Minor、Normal、Major、Critical等。
- 根據模塊、系統、可重現性等與項目緊密相關的分類。
但是這些Bug系統往往忽略了一個很重要的分類方式，那就是“按Bug影響面分類”，在這種分類模式下，一個Bug可以根據其影響的范圍來進行區分：
- 項目型Bug
-
與當前項目的業務流程、邏輯等有緊密關系的Bug，此類Bug只可能在當前項目中出現，離開了項目的大環境就沒有任何存在的意義。
針對此類的Bug，只需要在當前的環境下修復即可，不需要考慮太多的問題。
- 復發型Bug
-
此類Bug通常也與項目有緊密的關系，但是此類Bug在項目的整個演化過程中一而再再而三的出現，也許每一次出現的原因有些許差異，但表現上極其相似。比如某系統每天下午17：00左右會出現無法提供服務的情況，在第一輪修復的情況下，幾周后繼續出現此類情況。
在這樣的前提下，該問題就應該被評定為復發型Bug。對于復發型Bug，項目管理層及開發人員都應該給予絕對的重視，投入足夠的人力和時間來對問題進行徹底的跟蹤和追查，以期從根本上進行解決。
同時，在問題被定位并修復后，可以進行一次case study，以杜絕此類問題的再次發生。
- 通用型Bug
-
此類Bug是我認為當前的Bug系統最沒有關注到的一個問題，而且相比前面兩類Bug往往可以在項目層面通過制度和流程來進行規范，通用型Bug是一個最需要自動化處理的問題。這往往涉及到不同團隊之間的合作，也是Bug平臺成為一個知識庫的最為基礎的條件。
顧名思義，通用型Bug即與項目本身的業務沒有任何關系的，僅僅是技術上存在的問題。比如我最近發現的一個Bug，其可以用以下的代碼來表現：
<!DOCTYPE html>
<head>
<base target="_blank" />
<body>
<script>
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
iframe.contentWindow.location = 'javascript:;';
// 以上代碼會在IE9下彈出一個窗口
</script>這個Bug很明顯，是不屬于任何項目的，即所有項目在特定的情況下都可能使用類似的代碼，產生相同的Bug。
在這樣的情況下，如果將這個Bug繼續劃定在某個項目之下，那么他最多只能為一個項目提供幫助，防止該項目再次出現類似的問題。因此我們各項目組間可能經常能看到這樣的對話：
A：Hi，我們這邊發現一個問題，具體是…………這樣的，你們有相關經驗嗎？
B：哈哈，這個我們前段時間才遇上過，解決方法是…………那樣的。A：謝謝，謝謝！！
確實，這樣的場景很多，甚至能貫以“項目之間善于交流”的美名，但是如果認真地去思考，這樣的場景真的有必要嗎？如果有一個自動化的平臺，會將這些通用的Bug都公布出來，每個人各取所需進行關注、記錄，又怎么會出現這樣的對話呢？
交流，哪怕是使用最好的方式進行最有效的溝通，始終是有一定的成本的。同時，交流通常是1v1的關系，即便頻繁的接觸、溝通，一個知識也很難以廣播的形式讓盡可能多地需要他的人接收到。
正因如此，我才認為一個Bug系統的職責遠不止記錄、處理、關閉Bug，而應該作為一個知識的集散地，在團隊的發展中起更大的作用。
通用性Bug處理平臺
前面也提到，對于通用型Bug，平臺應該有能力對其進行分發、通告，在這里再詳細地總結一下，一個較為完善的Bug平臺，在處理通用型Bug方面應該至少有以下的特色：
- Bug的tag
- 無論系統內置使用怎么樣的方式來對Bug進行分類，其分類的維度總會有照顧不周之處。因此在Bug平臺中應該引入tag的概念，讓每一個Bug都能夠有一個或多個tag，使用tag這種通用的方式來標識一個Bug的屬性，也進一步方便了靈活的分類。
- Bug的訂閱
- 在Bug有了tag之后，所有擁有相應權限的人都可以訂閱其指定的tag的通用型Bug。當一個Bug被提升為通用型Bug時，Bug平臺會找到所有訂閱了這個Bug擁有的tag的用戶，并通過郵件等形式向其發送該Bug報告。而隨后Bug的每一個處理環節都會有郵件等形式的廣播。
- Bug的共享
- 在Bug可以被訂閱和廣播的同時，通用型Bug應該允許每一個有權限（并且此類權限應該放得很寬松）的用戶來參與討論、修補，每一個人都可以提交解決方案，再由相應的QA進行驗證后給予實行。這樣的效率遠大于一個項目的開發人員獨自苦苦掙扎，因為很可能有某個人曾經遇上過這個問題，對他來說提供解決方案僅僅是舉手之勞。
Bug的生命周期
當前多數的Bug平臺將Bug的狀態分為幾個階段，一般是Open -> Resolved -> Closed這樣的過程，但這其實遠遠沒有涵蓋一個Bug處理過程中應該有的環節。
當然作為一個簡單、現實為上的Bug系統，其主要環節有以上三者足矣，但是如果需要將Bug平臺擴展成一個知識庫，就不得不添加更多的環節，以期得到更多的信息：
- Open，Bug的發現階段，此時創建一個Bug，通常這個動作由QA進行。任何可重現、不可重現、小頻率重現的問題都可以進入到這個階段。
- Reproduce Step Confirmed，Bug的重現步驟被確定，通常由QA提交。在這個階段的Bug通常是穩定的，至少通過QA提供的重現步驟能大概率地被重現出來。
- Reproduce Environment Confirmed，Bug的重現環境被確定，通常由開發人員提交。在這個階段，在正常的重現步驟之外，開發人員已經可以提供一個最簡的環境來復現問題，可能是一段非常精簡的代碼，也可能是一個很簡單的步驟，其特點是這個重現的環境遠比QA的按步操作來得簡單，甚至可能得以自動化的重現。如果問題可以自動化重現和確定，則可以考慮將自動化腳本作為單元測試保存。
- Reason Found，問題的根本原因被確定，通常由開發人員提交。在這個階段，開發人員需要描述問題產生的原因，可能是某個業務邏輯的理解有分歧、或者某個第三方產品確實存在Bug、或者某段代碼存在著函數使用的錯誤等。
- Resolution Submitted，解決方案已提交，通常由開發人員進行。在這個階段，開發人員提交一個完整的解決方案，根據開發人員的思路，這個解決方案確實得以修復該問題。隨后同項目級的人員、QA可以對該解決方案進行評估，確定對其他模塊不會有影響等。
- Resolution Applied，已經應用了解決方案，通常由開發人員提交。此時開發人員指定一個新的源碼版本號，該版本號中的相應代碼段應用了第5步中提交的解決方案，問題應當已經修復。
- Resolution Confirmed，問題已經確定修復，由QA人員提交。此階段QA確定問題已經被修復，并且經過了一定范圍的回歸測試，確保問題不會對其他模塊產生嚴重影響。在這個階段，Bug依舊是開放狀態，各成員可以對Bug進行參與，作一些總結性的討論。
- Close，Bug關閉，此時Bug已經鎖定，可以作為一個固定的知識項來查看，但不再有修改和討論的可能性。
以上為一個非常周全的Bug生命周期管理，但確實不需要對其進行一個強制的要求。一個Bug平臺可以提供這些生命周期，也許只是簡單地在“Bug狀態”中添加相應的項，而進一步如何引導用戶對這些環節進行充分的利用，則可以通過團隊的規章、Bug平臺本身的界面等方面來進行，強硬地規定只會讓Bug追蹤過程事倍功半。
其他方面的增強
上文提的是個人認為Bug平臺向知識庫整合過程中最重要的一環，即通用型Bug的分類、分享、訂閱工作，以此為其他來散布眾多點狀知識，以期通過所有人員共同參與交流、溝通，再將點狀的知識整合成線狀甚至是面狀的知識體系，補充團隊的經驗和能力。
但是在此之外，其實Bug平臺還可以做很多事情，來提高這個“偽知識平臺”的使用體驗，證知識更加有條理、有結構：
-
與源碼平臺關聯
一個Bug平臺應該與源碼平臺有著非常緊密的關系，包括一個Bug在哪個版本（A）發現，在哪個版本（B）修復，并可以通過平臺找到源碼平臺中兩個版本的diff，比如scm.xxx.com/diff?file=abc&rev=A:B。這要求Bug平臺與源碼平臺都提供相應的接口，可以在兩個第三方系統間進行交互合作，現時也要求Bug平臺有一個嚴格的規范，在Bug的open和close操作中提供相關的版本號。
-
與知識平臺關聯
Bug是知識的來源，那么Bug提供的知識自然要進入到知識管理平臺。這一點需要系統的智能化識別，當一個Bug其信息足夠完善，包括了前面提到的Bug生命周期的各個環節應有的信息的時候，Bug平臺應該主動與知識平臺連接，將這個Bug整理成一份真正的知識文檔進入到知識管理平臺。
但是，在各個Bug系統之中，包括現在公司使用的Trace系統，無一例外地存在一些讓我不滿意之處，其中最大的原因就是很多Bug系統僅僅是作為Bug的記錄系統存在，而沒有試圖去讓一個Bug成為一個知識的積累，讓整個Bug系統變成一個豐富充實的知識庫。這樣的Bug系統，永遠都只是提供一個簡單的業務流程，不會變成干完人員、產品、甚至是整個團隊的進步的天梯。
在我看來，一個Bug系統應該更加全面，管理Bug的生命周期的同時，也用于管理一個產品、團隊的知識，更可以與周邊系統合作，形成一個真正的集成式管理平臺。
Bug的分類
現在的Bug系統，對Bug系統的分類通常有這么幾種：
* 根據性質：Bug、Feature、Enhancement等。
* 根據危險程度：Trival、Minor、Normal、Major、Critical等。
* 根據模塊、系統、可重現性等與項目緊密相關的分類。
但是這些Bug系統往往忽略了一個很重要的分類方式，那就是“按Bug影響面分類”，在這種分類模式下，一個Bug可以根據其影響的范圍來進行區分：
項目型Bug
與當前項目的業務流程、邏輯等有緊密關系的Bug，此類Bug只可能在當前項目中出現，離開了項目的大環境就沒有任何存在的意義。
針對此類的Bug，只需要在當前的環境下修復即可，不需要考慮太多的問題。
復發型Bug
此類Bug通常也與項目有緊密的關系，但是此類Bug在項目的整個演化過程中一而再再而三的出現，也許每一次出現的原因有些許差異，但表現上極其相似。比如某系統每天下午17：00左右會出現無法提供服務的情況，在第一輪修復的情況下，幾周后繼續出現此類情況。
在這樣的前提下，該問題就應該被評定為復發型Bug。對于復發型Bug，項目管理層及開發人員都應該給予絕對的重視，投入足夠的人力和時間來對問題進行徹底的跟蹤和追查，以期從根本上進行解決。
同時，在問題被定位并修復后，可以進行一次case study，以杜絕此類問題的再次發生。
通用型Bug
此類Bug是我認為當前的Bug系統最沒有關注到的一個問題，而且相比前面兩類Bug往往可以在項目層面通過制度和流程來進行規范，通用型Bug是一個最需要自動化處理的問題。這往往涉及到不同團隊之間的合作，也是Bug平臺成為一個知識庫的最為基礎的條件。
顧名思義，通用型Bug即與項目本身的業務沒有任何關系的，僅僅是技術上存在的問題。比如我最近發現的一個Bug，其可以用以下的代碼來表現：
<!DOCTYPE html>
<head>
<base target="_blank" />
<body>
<script>
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
iframe.contentWindow.location = 'javascript:;';
// 以上代碼會在IE9下彈出一個窗口
</script>
這個Bug很明顯，是不屬于任何項目的，即所有項目在特定的情況下都可能使用類似的代碼，產生相同的Bug。
在這樣的情況下，如果將這個Bug繼續劃定在某個項目之下，那么他最多只能為一個項目提供幫助，防止該項目再次出現類似的問題。因此我們各項目組間可能經常能看到這樣的對話：
A：Hi，我們這邊發現一個問題，具體是…………這樣的，你們有相關經驗嗎？
B：哈哈，這個我們前段時間才遇上過，解決方法是…………那樣的。
A：謝謝，謝謝！！
確實，這樣的場景很多，甚至能貫以“項目之間善于交流”的美名，但是如果認真地去思考，這樣的場景真的有必要嗎？如果有一個自動化的平臺，會將這些通用的Bug都公布出來，每個人各取所需進行關注、記錄，又怎么會出現這樣的對話呢？
交流，哪怕是使用最好的方式進行最有效的溝通，始終是有一定的成本的。同時，交流通常是1v1的關系，即便頻繁的接觸、溝通，一個知識也很難以廣播的形式讓盡可能多地需要他的人接收到。
正因如此，我才認為一個Bug系統的職責遠不止記錄、處理、關閉Bug，而應該作為一個知識的集散地，在團隊的發展中起更大的作用。
通用性Bug處理平臺
前面也提到，對于通用型Bug，平臺應該有能力對其進行分發、通告，在這里再詳細地總結一下，一個較為完善的Bug平臺，在處理通用型Bug方面應該至少有以下的特色：
Bug的tag
無論系統內置使用怎么樣的方式來對Bug進行分類，其分類的維度總會有照顧不周之處。因此在Bug平臺中應該引入tag的概念，讓每一個Bug都能夠有一個或多個tag，使用tag這種通用的方式來標識一個Bug的屬性，也進一步方便了靈活的分類。
Bug的訂閱
在 Bug有了tag之后，所有擁有相應權限的人都可以訂閱其指定的tag的通用型Bug。當一個Bug被提升為通用型Bug時，Bug平臺會找到所有訂閱了這個Bug擁有的tag的用戶，并通過郵件等形式向其發送該Bug報告。而隨后Bug的每一個處理環節都會有郵件等形式的廣播。
Bug的共享
在 Bug可以被訂閱和廣播的同時，通用型Bug應該允許每一個有權限（并且此類權限應該放得很寬松）的用戶來參與討論、修補，每一個人都可以提交解決方案，再由相應的QA進行驗證后給予實行。這樣的效率遠大于一個項目的開發人員獨自苦苦掙扎，因為很可能有某個人曾經遇上過這個問題，對他來說提供解決方案僅僅是舉手之勞。
Bug的生命周期
當前多數的Bug平臺將Bug的狀態分為幾個階段，一般是Open -> Resolved -> Closed這樣的過程，但這其實遠遠沒有涵蓋一個Bug處理過程中應該有的環節。
當然作為一個簡單、現實為上的Bug系統，其主要環節有以上三者足矣，但是如果需要將Bug平臺擴展成一個知識庫，就不得不添加更多的環節，以期得到更多的信息：
1. Open，Bug的發現階段，此時創建一個Bug，通常這個動作由QA進行。任何可重現、不可重現、小頻率重現的問題都可以進入到這個階段。
2. Reproduce Step Confirmed，Bug的重現步驟被確定，通常由QA提交。在這個階段的Bug通常是穩定的，至少通過QA提供的重現步驟能大概率地被重現出來。
3. Reproduce Environment Confirmed，Bug的重現環境被確定，通常由開發人員提交。在這個階段，在正常的重現步驟之外，開發人員已經可以提供一個最簡的環境來復現問題，可能是一段非常精簡的代碼，也可能是一個很簡單的步驟，其特點是這個重現的環境遠比QA的按步操作來得簡單，甚至可能得以自動化的重現。如果問題可以自動化重現和確定，則可以考慮將自動化腳本作為單元測試保存。
4. Reason Found，問題的根本原因被確定，通常由開發人員提交。在這個階段，開發人員需要描述問題產生的原因，可能是某個業務邏輯的理解有分歧、或者某個第三方產品確實存在Bug、或者某段代碼存在著函數使用的錯誤等。
5. Resolution Submitted，解決方案已提交，通常由開發人員進行。在這個階段，開發人員提交一個完整的解決方案，根據開發人員的思路，這個解決方案確實得以修復該問題。隨后同項目級的人員、QA可以對該解決方案進行評估，確定對其他模塊不會有影響等。
6. Resolution Applied，已經應用了解決方案，通常由開發人員提交。此時開發人員指定一個新的源碼版本號，該版本號中的相應代碼段應用了第5步中提交的解決方案，問題應當已經修復。
7. Resolution Confirmed，問題已經確定修復，由QA人員提交。此階段QA確定問題已經被修復，并且經過了一定范圍的回歸測試，確保問題不會對其他模塊產生嚴重影響。在這個階段，Bug依舊是開放狀態，各成員可以對Bug進行參與，作一些總結性的討論。
8. Close，Bug關閉，此時Bug已經鎖定，可以作為一個固定的知識項來查看，但不再有修改和討論的可能性。
以上為一個非常周全的Bug生命周期管理，但確實不需要對其進行一個強制的要求。一個Bug平臺可以提供這些生命周期，也許只是簡單地在 “Bug狀態”中添加相應的項，而進一步如何引導用戶對這些環節進行充分的利用，則可以通過團隊的規章、Bug平臺本身的界面等方面來進行，強硬地規定只會讓Bug追蹤過程事倍功半。
其他方面的增強
上文提的是個人認為Bug平臺向知識庫整合過程中最重要的一環，即通用型Bug的分類、分享、訂閱工作，以此為其他來散布眾多點狀知識，以期通過所有人員共同參與交流、溝通，再將點狀的知識整合成線狀甚至是面狀的知識體系，補充團隊的經驗和能力。
但是在此之外，其實Bug平臺還可以做很多事情，來提高這個“偽知識平臺”的使用體驗，證知識更加有條理、有結構：
*
與源碼平臺關聯
一個Bug平臺應該與源碼平臺有著非常緊密的關系，包括一個Bug在哪個版本（A）發現，在哪個版本（B）修復，并可以通過平臺找到源碼平臺中兩個版本的diff，比如scm.xxx.com/diff?file=abc&rev=A:B。這要求Bug平臺與源碼平臺都提供相應的接口，可以在兩個第三方系統間進行交互合作，現時也要求Bug平臺有一個嚴格的規范，在Bug的open和close操作中提供相關的版本號。
*
與知識平臺關聯
Bug是知識的來源，那么Bug提供的知識自然要進入到知識管理平臺。這一點需要系統的智能化識別，當一個Bug其信息足夠完善，包括了前面提到的 Bug生命周期的各個環節應有的信息的時候，Bug平臺應該主動與知識平臺連接，將這個Bug整理成一份真正的知識文檔進入到知識管理平臺。
留言列表
