![1.png](https://ucc.alicdn.com/pic/developer-ecology/7878abf5f9fb40afa5308adbde43a8e9.png)

作者 | 嵩華

> **導讀**：缺陷分析做得好，bug 寫得少。阿里資深技術專家和你分享如何進行高質量的缺陷分析，總結了 5 個要點，透過缺陷分析消除開發中的各種盲點，打造一個學習型的團隊。

軟體開發中的缺陷隱含著極高的價值，但是許多組織都僅僅忍受了缺陷帶來的成本和後果，卻讓價值白白溜掉了。

缺陷的價值是其觸發的學習和成長的機會。把握缺陷帶來的學習機會，可以快速提高組織的能力，未來的缺陷更少，成本更低，更容易成功。但同時，有效的缺陷分析和跟蹤行動需要有效的方法和相應的組織的支援。

# 缺陷隱含著極高的價值

最近我們做了一次關於缺陷分析的工作坊。

> “發生缺陷是一件好事嗎？” 在工作坊開始的時候，我這麼問參與的同學。
> “那當然是一件壞事了。”
> “不管是不是好事，它就在那兒。我覺得無所謂好不好，這是一件正常的事情。”
>  “這麼說好像也對，但是缺陷很麻煩，我沒法喜歡缺陷。”

是的，沒有人喜歡缺陷，它消耗研發成本，影響開發週期，但同時，缺陷又和軟體開發如影隨形，無論多少，始終都在。這是為什麼呢？

看下面的這張圖：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/6a936625b95f4c03a5fe630f134deadb.png)
軟體開發是消除不確定性的過程

軟體開發和工業生產完全不同。工業生產透過消除過程中的各種可變性，能夠逐步逼近零缺陷的目標。所以，六西格瑪方法在工業生產中非常行之有效。

軟體開發的過程則恰恰相反。每一次開發，都是不確定的，我們往往都是在專案臨近結束的時候，對整個專案的各種問題和細節才變得清晰。在這種假設下，與其追求零缺陷，倒不如說是我們應該追求降低缺陷的影響，比如，在缺陷產生的第一時間（注入時間甚至注入之前）就發現缺陷——因為這時候缺陷的成本幾乎為零，這也就可以等價為“零缺陷”了吧。

如果說工業生產中的六西格瑪方法來自於對生產系統的打造，那麼，在軟體開發中，“零缺陷”對應的系統是什麼呢？它當然包含軟體研發的流程和工具，但是，在我看來，最重要的，應該是打造軟體的核心主體——人。透過缺陷分析來持續學習，才能不浪費缺陷所消耗的成本。

# 為什麼會重複踩坑

有不少團隊是有缺陷原因分析的。我曾經仔細分析過一個團隊的缺陷原因分析，發現了下面這些缺陷原因的高頻詞：

- 編碼有問題，下次寫程式碼的時候想的更仔細一些。
- 程式碼評審做的不好。下次程式碼評審要充分。
- 業務場景分析不全面，下次分析的更全面一些。
- ......

我相信，寫下上述原因分析的同學，內心一定是很真誠的，也是真心覺得自己當時程式碼寫的不夠好，業務場景分析的不全面，程式碼評審不夠充分。但是，這個分析帶來的行動，卻往往是不可達成的。是真的想的不仔細嗎，還是就是想不到？這次評審做的不好，下次就肯定能做好了嗎？這次場景分析不全，那麼怎麼才能更全呢?

這種原因分析過於寬泛了，以至於很難產生實際有效的改進行動，下次往往還是會在同樣的地方跌倒——大家只要看一下在既往的原因分析中，有多少次類似的答案？每一次重複，就是一次新的踩坑。

還有一類原因分析，恰恰相反，又過於具體化了，具體化到了沒有學習價值的層面上。例如，這是當時設計的不對，A 服務就不該呼叫 B 服務，A 服務應該考慮到B服務呼叫中的異常場景，等等。好吧，缺陷現在已經修復了，A 服務呼叫 B 服務出現的異常場景已經固化在程式碼中了，下一次如果是 C 服務呼叫 D 服務的異常場景應該怎麼辦呢？

最合適的缺陷原因應該基於這樣的標準：這些原因需要形成系統化的可行動的結果。這個標準的檢驗方式是：下一次如果發生某某場景，我們的應對方案是否有效?

# 做好缺陷分析的 5 個要點

在實踐中，我們總結了 5 個要點，來最大化出於學習目的的缺陷分析的實踐操作。它們是：

- 及時總結，設定卡點
- 結對分析，小組總結
- 負面清單支援下的全量分析
- 可操作的結果
- 團體學習，機制建設

# 及時總結，設定卡點

> “缺陷分析很重要，但是研發同學都太忙了，我們兩個月集中做一次怎麼樣？”

別那麼緊張——及時才是最節約的方式。要從忙碌中解放出來，每次花 15 分鐘，做一次有效的缺陷分析，時間已經妥妥的啦。

缺陷分析的最好時間是缺陷修復完成的時間。此時記憶最新鮮、也能早收益。如果一個缺陷已經過去了兩個月，那麼缺陷分析的成本就變高了，得找回原來的記憶和當時的上下文，這個記憶準確不準確還是另一回事。

怎樣才能保證及時地做，從而保證這些重要而不緊急的事情發生呢？一個比較有效的方式，是設定流程中的卡點：當缺陷被設定為已修復狀態、或者設定為已關閉狀態時，強制把缺陷分析設定為一個流程卡點，這樣就能形成比較好的驅動。

# 結對分析，小組總結

誰來負責缺陷分析？是讓具體這個缺陷的同學來做，還是召集整個團隊一起？

召集整個團隊來做缺陷分析，有時候代價過於高昂。即使僅僅分析比較後期的線上問題，即使每個缺陷僅僅分析 15 分鐘：100 個缺陷，每個團隊 8 個人，乘積就是 12,000分鐘，合 200 個小時，也是一個驚人的數字，投入產出不成比例。

解決缺陷的同學確實是對這個缺陷理解最好。但是，這會不會形成“單點問題”，降低問題分析的有效性？

我們的方案是：

## 1. 把結對分析作為制度

讓解決缺陷的同學擔任負責人，搭配上一個小夥伴。結對既形成了知識方面的互補，一定程度上消除了思維盲點，也透過結對形成了更深入的討論，也提前進行結果的“驗收”，提高分析的質量。如果有必要，結對的小組可以自主決定是否引入其他人參與。

## 2. 團隊定期討論學習

團隊定期對重要的缺陷分析結果進行討論，既是對小組成果的驗收，更有利於在團隊成員間形成傳播，互相學習。

# 負面清單支援下的全量分析

缺陷分析的目的是提升，所以，重在解決那些“未知的未知”的問題。顯然不是每個缺陷都應該深入分析。但是，如果我們針對每個缺陷都定義它該不該分析，又會導致決策成本過高，而且質量也不可靠。所以，我們的做法是在預設全量的基礎上，使用負面清單進行過濾。凡是負面清單不存在的，都進行缺陷分析。負面清單是團隊級別的。每個團隊都應該維護自己的列表，例如：

- 偶發問題
- 已經列在改進項中的問題（不斷擴充）

這個事情和淘金有些類似，明確不要什麼，能更高效地避免那些真正值得做的事情不被淹沒。事實上，每次缺陷分析都會擴充負面清單的長度，所需的缺陷分析數量將越來越少，問題越來越聚焦，時間也越來越節省。

# 可操作的結果

缺陷分析應該產生有價值的洞見，足夠的深度是重點。在如何產生深度洞見方面已經有非常多成熟的方法，最典型的是 5 Whys，此外還有魚骨圖等著名工具可用。為了控制篇幅，本文略去對這些方法的介紹，只透過一個例項來說明在實際的缺陷分析中，我們是如何產生深度洞見的。

某缺陷描述瞭如下的場景（該例項在不影響問題說明的情況下做了適度抽象）：

使用者持有某個虛擬裝置，該裝置有一些附屬資源，當使用者刪除裝置時，該裝置的附屬資源應該被釋放。但是，發現在一種特殊場景下，這個附屬資源並沒有得到釋放。

程式碼如下：

```
void releaseResources (resoure_id){    
    if (failedOfHardwareResourceRelease(resource_id)){        
        writeLog("resource release failed");    
    }
}
```

下面是關於這個問題的對話：

> “原因是什麼？”
> “我們沒有在需求分析階段考慮到這種釋放不成功的場景。”
> “OK。需求分析是問題，這是一個改進點。——但是更重要的：最後發現這個問題的最直接的機會點是哪個時間點？”
> “寫程式碼的時候。”
> “寫程式碼的時候我們注意到這個問題了嗎？”
> “注意到了啊，所以寫了 log，但是沒仔細想應該怎麼處理。這說明我們對這段程式碼的職責定義不清晰。”
> “也許我們可以在程式設計規範中加入一條：出現異常場景時不應該只記錄 log，而應該和負責人澄清場景和處理方案。在未來，當出現了僅僅出現寫錯誤 log，但是沒有其他處理的時候，我們就能注意到這一點。”

檢驗分析深度是否足夠，最直接的指標就是產生的結果是否是“可行動的”。如果一個結果是不可行動的，往往意味著深度或者抽象不夠。

# 團體學習，機制建設

學習型組織並不總是容易建立。除了上述心智模型和操作方法之外，組織機制往往是成功的重點。我們總結了如下幾點：

- 是長期存在的團隊
- 建立持續學習的心智模型
- 持續維護和利用本組織的智力資產

這幾點似乎都毋需多言。但是關於智力資產，還是要多強調一下：分析結果最後可能會是流程改進、程式設計習慣和程式設計規範、程式碼評審的檢查單、設計能力的提升、引入某些新的工程實踐如例項化需求等，不外乎有兩類：

## 1. 短期的行動

例如引入例項化需求實踐、 建設自動化測試機制等。對於這類具體行動，要定義責任人和結束日期，並且把它們和管理需求等工作項同等管理起來，確保其發生。

## 2. 長期的規則

這類是需要持續關注的東西，例如程式碼評審的常見問題列表、採納某種設計思想如契約式設計、防禦式程式設計等。對於這類問題，由於需要持續關注，需要維護它們，並把它們作為團隊資產的一部分。當然了，如果技術上可行，還是要把其中的一部分儘早做成工具，減少記憶負擔，提升可操作性。

這種資產維護的越多，就會發現未來需要繼續分析的缺陷越少——當然了，這也是一切資產的共性所在。

# 總結

現實情況紛繁複雜，統一的方法往往並不存在。但是心智模型和一定的規律、思路還是存在的。本文聚焦於透過缺陷分析進行學習。

透過適當的方法，它可以在可控的時間投入下，為組織積累寶貴的財富，並且在未來的開發中得到數倍、數十倍上百倍的回報。忙碌不是理由，在未來少掉一個新 bug，就賺回來了。

透過缺陷分析，我們可以形成如下的產出：

- 建立團隊關於需求分析、軟體設計、程式設計、測試、運維等方面的共同心智
- 形成常見問題的檢查單
- 採用或者開發新的工具
- 改進既有流程
- 形成針對特定問題的行動計劃

最最重要的，透過消除各種盲點，我們的能力也就越來越強，開發也就越來越順暢，距離零缺陷的目標，就越來越近了。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495997&idx=1&sn=7a9b093c1702ce05f4745868819b4632&chksm=fae6faf2cd9173e481592747db56f9118e2d0beca3c1184998482b8246698f5f65002ef8ef96&token=1794504628&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

高質量的缺陷分析：讓自己少寫 bug

相關文章