缺陷分析做得好，bug 寫得少。阿里資深技術(shù)專家和你分享如何進(jìn)行高質(zhì)量的缺陷分析，總結(jié)了 5 個(gè)要點(diǎn)，通過缺陷分析消除開發(fā)中的各種盲點(diǎn)，打造一個(gè)學(xué)習(xí)型的團(tuán)隊(duì)。

軟件開發(fā)中的缺陷隱含著極高的價(jià)值，但是許多組織都僅僅忍受了缺陷帶來的成本和后果，卻讓價(jià)值白白溜掉了。

缺陷的價(jià)值是其觸發(fā)的學(xué)習(xí)和成長的機(jī)會。把握缺陷帶來的學(xué)習(xí)機(jī)會，可以快速提高組織的能力，未來的缺陷更少，成本更低，更容易成功。但同時(shí)，有效的缺陷分析和跟蹤行動需要有效的方法和相應(yīng)的組織的支持。

缺陷隱含著極高的價(jià)值

最近我們做了一次關(guān)于缺陷分析的工作坊。

“發(fā)生缺陷是一件好事嗎?” 在工作坊開始的時(shí)候，我這么問參與的同學(xué)。

“那當(dāng)然是一件壞事了。”

“不管是不是好事，它就在那兒。我覺得無所謂好不好，這是一件正常的事情。”

“這么說好像也對，但是缺陷很麻煩，我沒法喜歡缺陷。”

是的，沒有人喜歡缺陷，它消耗研發(fā)成本，影響開發(fā)周期，但同時(shí)，缺陷又和軟件開發(fā)如影隨形，無論多少，始終都在。這是為什么呢?

看下面的這張圖：

??

軟件開發(fā)是消除不確定性的過程

軟件開發(fā)和工業(yè)生產(chǎn)完全不同。工業(yè)生產(chǎn)通過消除過程中的各種可變性，能夠逐步逼近零缺陷的目標(biāo)。所以，六西格瑪方法在工業(yè)生產(chǎn)中非常行之有效。

軟件開發(fā)的過程則恰恰相反。每一次開發(fā)，都是不確定的，我們往往都是在項(xiàng)目臨近結(jié)束的時(shí)候，對整個(gè)項(xiàng)目的各種問題和細(xì)節(jié)才變得清晰。在這種假設(shè)下，與其追求零缺陷，倒不如說是我們應(yīng)該追求降低缺陷的影響，比如，在缺陷產(chǎn)生的第一時(shí)間(注入時(shí)間甚至注入之前)就發(fā)現(xiàn)缺陷——因?yàn)檫@時(shí)候缺陷的成本幾乎為零，這也就可以等價(jià)為“零缺陷”了吧。

如果說工業(yè)生產(chǎn)中的六西格瑪方法來自于對生產(chǎn)系統(tǒng)的打造，那么，在軟件開發(fā)中，“零缺陷”對應(yīng)的系統(tǒng)是什么呢?它當(dāng)然包含軟件研發(fā)的流程和工具，但是，在我看來，最重要的，應(yīng)該是打造軟件的核心主體——人。通過缺陷分析來持續(xù)學(xué)習(xí)，才能不浪費(fèi)缺陷所消耗的成本。

為什么會重復(fù)踩坑

有不少團(tuán)隊(duì)是有缺陷原因分析的。我曾經(jīng)仔細(xì)分析過一個(gè)團(tuán)隊(duì)的缺陷原因分析，發(fā)現(xiàn)了下面這些缺陷原因的高頻詞：

• 編碼有問題，下次寫代碼的時(shí)候想的更仔細(xì)一些。
• 代碼評審做的不好。下次代碼評審要充分。
• 業(yè)務(wù)場景分析不全面，下次分析的更全面一些。
• ......

我相信，寫下上述原因分析的同學(xué)，內(nèi)心一定是很真誠的，也是真心覺得自己當(dāng)時(shí)代碼寫的不夠好，業(yè)務(wù)場景分析的不全面，代碼評審不夠充分。但是，這個(gè)分析帶來的行動，卻往往是不可達(dá)成的。是真的想的不仔細(xì)嗎，還是就是想不到?這次評審做的不好，下次就肯定能做好了嗎?這次場景分析不全，那么怎么才能更全呢?

這種原因分析過于寬泛了，以至于很難產(chǎn)生實(shí)際有效的改進(jìn)行動，下次往往還是會在同樣的地方跌倒——大家只要看一下在既往的原因分析中，有多少次類似的答案?每一次重復(fù)，就是一次新的踩坑。

還有一類原因分析，恰恰相反，又過于具體化了，具體化到了沒有學(xué)習(xí)價(jià)值的層面上。例如，這是當(dāng)時(shí)設(shè)計(jì)的不對，A 服務(wù)就不該調(diào)用 B 服務(wù)，A 服務(wù)應(yīng)該考慮到B服務(wù)調(diào)用中的異常場景，等等。好吧，缺陷現(xiàn)在已經(jīng)修復(fù)了，A 服務(wù)調(diào)用 B 服務(wù)出現(xiàn)的異常場景已經(jīng)固化在代碼中了，下一次如果是 C 服務(wù)調(diào)用 D 服務(wù)的異常場景應(yīng)該怎么辦呢?

最合適的缺陷原因應(yīng)該基于這樣的標(biāo)準(zhǔn)：這些原因需要形成系統(tǒng)化的可行動的結(jié)果。這個(gè)標(biāo)準(zhǔn)的檢驗(yàn)方式是：下一次如果發(fā)生某某場景，我們的應(yīng)對方案是否有效?

做好缺陷分析的 5 個(gè)要點(diǎn)

在實(shí)踐中，我們總結(jié)了 5 個(gè)要點(diǎn)，來最大化出于學(xué)習(xí)目的的缺陷分析的實(shí)踐操作。它們是：

• 及時(shí)總結(jié)，設(shè)置卡點(diǎn)
• 結(jié)對分析，小組總結(jié)
• 負(fù)面清單支持下的全量分析
• 可操作的結(jié)果
• 團(tuán)體學(xué)習(xí)，機(jī)制建設(shè)

及時(shí)總結(jié)，設(shè)置卡點(diǎn)

“缺陷分析很重要，但是研發(fā)同學(xué)都太忙了，我們兩個(gè)月集中做一次怎么樣?”

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

缺陷分析的最好時(shí)間是缺陷修復(fù)完成的時(shí)間。此時(shí)記憶最新鮮、也能早收益。如果一個(gè)缺陷已經(jīng)過去了兩個(gè)月，那么缺陷分析的成本就變高了，得找回原來的記憶和當(dāng)時(shí)的上下文，這個(gè)記憶準(zhǔn)確不準(zhǔn)確還是另一回事。

怎樣才能保證及時(shí)地做，從而保證這些重要而不緊急的事情發(fā)生呢?一個(gè)比較有效的方式，是設(shè)置流程中的卡點(diǎn)：當(dāng)缺陷被設(shè)定為已修復(fù)狀態(tài)、或者設(shè)定為已關(guān)閉狀態(tài)時(shí)，強(qiáng)制把缺陷分析設(shè)定為一個(gè)流程卡點(diǎn)，這樣就能形成比較好的驅(qū)動。

結(jié)對分析，小組總結(jié)

誰來負(fù)責(zé)缺陷分析?是讓具體這個(gè)缺陷的同學(xué)來做，還是召集整個(gè)團(tuán)隊(duì)一起?

召集整個(gè)團(tuán)隊(duì)來做缺陷分析，有時(shí)候代價(jià)過于高昂。即使僅僅分析比較后期的線上問題，即使每個(gè)缺陷僅僅分析 15 分鐘：100 個(gè)缺陷，每個(gè)團(tuán)隊(duì) 8 個(gè)人，乘積就是 12,000分鐘，合 200 個(gè)小時(shí)，也是一個(gè)驚人的數(shù)字，投入產(chǎn)出不成比例。

解決缺陷的同學(xué)確實(shí)是對這個(gè)缺陷理解最好。但是，這會不會形成“單點(diǎn)問題”，降低問題分析的有效性?

我們的方案是：

把結(jié)對分析作為制度

讓解決缺陷的同學(xué)擔(dān)任負(fù)責(zé)人，搭配上一個(gè)小伙伴。結(jié)對既形成了知識方面的互補(bǔ)，一定程度上消除了思維盲點(diǎn)，也通過結(jié)對形成了更深入的討論，也提前進(jìn)行結(jié)果的“驗(yàn)收”，提高分析的質(zhì)量。如果有必要，結(jié)對的小組可以自主決定是否引入其他人參與。

團(tuán)隊(duì)定期討論學(xué)習(xí)

團(tuán)隊(duì)定期對重要的缺陷分析結(jié)果進(jìn)行討論，既是對小組成果的驗(yàn)收，更有利于在團(tuán)隊(duì)成員間形成傳播，互相學(xué)習(xí)。

負(fù)面清單支持下的全量分析

缺陷分析的目的是提升，所以，重在解決那些“未知的未知”的問題。顯然不是每個(gè)缺陷都應(yīng)該深入分析。但是，如果我們針對每個(gè)缺陷都定義它該不該分析，又會導(dǎo)致決策成本過高，而且質(zhì)量也不可靠。所以，我們的做法是在默認(rèn)全量的基礎(chǔ)上，使用負(fù)面清單進(jìn)行過濾。凡是負(fù)面清單不存在的，都進(jìn)行缺陷分析。負(fù)面清單是團(tuán)隊(duì)級別的。每個(gè)團(tuán)隊(duì)都應(yīng)該維護(hù)自己的列表，例如：

• 偶發(fā)問題
• 已經(jīng)列在改進(jìn)項(xiàng)中的問題(不斷擴(kuò)充)

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

可操作的結(jié)果

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

某缺陷描述了如下的場景(該實(shí)例在不影響問題說明的情況下做了適度抽象)：

用戶持有某個(gè)虛擬設(shè)備，該設(shè)備有一些附屬資源，當(dāng)用戶刪除設(shè)備時(shí)，該設(shè)備的附屬資源應(yīng)該被釋放。但是，發(fā)現(xiàn)在一種特殊場景下，這個(gè)附屬資源并沒有得到釋放。

代碼如下：

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

下面是關(guān)于這個(gè)問題的對話：

“原因是什么?”

“我們沒有在需求分析階段考慮到這種釋放不成功的場景。”

“OK。需求分析是問題，這是一個(gè)改進(jìn)點(diǎn)。——但是更重要的：最后發(fā)現(xiàn)這個(gè)問題的最直接的機(jī)會點(diǎn)是哪個(gè)時(shí)間點(diǎn)?”

“寫代碼的時(shí)候。”

“寫代碼的時(shí)候我們注意到這個(gè)問題了嗎?”

“注意到了啊，所以寫了 log，但是沒仔細(xì)想應(yīng)該怎么處理。這說明我們對這段代碼的職責(zé)定義不清晰。”

“也許我們可以在編程規(guī)范中加入一條：出現(xiàn)異常場景時(shí)不應(yīng)該只記錄 log，而應(yīng)該和負(fù)責(zé)人澄清場景和處理方案。在未來，當(dāng)出現(xiàn)了僅僅出現(xiàn)寫錯誤 log，但是沒有其他處理的時(shí)候，我們就能注意到這一點(diǎn)。”

檢驗(yàn)分析深度是否足夠，最直接的指標(biāo)就是產(chǎn)生的結(jié)果是否是“可行動的”。如果一個(gè)結(jié)果是不可行動的，往往意味著深度或者抽象不夠。

團(tuán)體學(xué)習(xí)，機(jī)制建設(shè)

學(xué)習(xí)型組織并不總是容易建立。除了上述心智模型和操作方法之外，組織機(jī)制往往是成功的重點(diǎn)。我們總結(jié)了如下幾點(diǎn)：

• 是長期存在的團(tuán)隊(duì)
• 建立持續(xù)學(xué)習(xí)的心智模型
• 持續(xù)維護(hù)和利用本組織的智力資產(chǎn)

這幾點(diǎn)似乎都毋需多言。但是關(guān)于智力資產(chǎn)，還是要多強(qiáng)調(diào)一下：分析結(jié)果最后可能會是流程改進(jìn)、編程習(xí)慣和編程規(guī)范、代碼評審的檢查單、設(shè)計(jì)能力的提升、引入某些新的工程實(shí)踐如實(shí)例化需求等，不外乎有兩類：

短期的行動

例如引入實(shí)例化需求實(shí)踐、 建設(shè)自動化測試機(jī)制等。對于這類具體行動，要定義責(zé)任人和結(jié)束日期，并且把它們和管理需求等工作項(xiàng)同等管理起來，確保其發(fā)生。

長期的規(guī)則

這類是需要持續(xù)關(guān)注的東西，例如代碼評審的常見問題列表、采納某種設(shè)計(jì)思想如契約式設(shè)計(jì)、防御式編程等。對于這類問題，由于需要持續(xù)關(guān)注，需要維護(hù)它們，并把它們作為團(tuán)隊(duì)資產(chǎn)的一部分。當(dāng)然了，如果技術(shù)上可行，還是要把其中的一部分盡早做成工具，減少記憶負(fù)擔(dān)，提升可操作性。

這種資產(chǎn)維護(hù)的越多，就會發(fā)現(xiàn)未來需要繼續(xù)分析的缺陷越少——當(dāng)然了，這也是一切資產(chǎn)的共性所在。

總結(jié)

現(xiàn)實(shí)情況紛繁復(fù)雜，統(tǒng)一的方法往往并不存在。但是心智模型和一定的規(guī)律、思路還是存在的。本文聚焦于通過缺陷分析進(jìn)行學(xué)習(xí)。

通過適當(dāng)?shù)姆椒ǎ梢栽诳煽氐臅r(shí)間投入下，為組織積累寶貴的財(cái)富，并且在未來的開發(fā)中得到數(shù)倍、數(shù)十倍上百倍的回報(bào)。忙碌不是理由，在未來少掉一個(gè)新 bug，就賺回來了。

通過缺陷分析，我們可以形成如下的產(chǎn)出：

• 建立團(tuán)隊(duì)關(guān)于需求分析、軟件設(shè)計(jì)、編程、測試、運(yùn)維等方面的共同心智
• 形成常見問題的檢查單
• 采用或者開發(fā)新的工具
• 改進(jìn)既有流程
• 形成針對特定問題的行動計(jì)劃

最最重要的，通過消除各種盲點(diǎn)，我們的能力也就越來越強(qiáng)，開發(fā)也就越來越順暢，距離零缺陷的目標(biāo)，就越來越近了。