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

2021-10-10 10:08:00 字數 4147 閱讀 9418

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

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

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

「發生缺陷是一件好事嗎?」 在工作坊開始的時候,我這麼問參與的同學。

「那當然是一件壞事了。」

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

「這麼說好像也對,但是缺陷很麻煩,我沒法喜歡缺陷。」

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

看下面的這張圖:

軟體開發是消除不確定性的過程

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

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

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

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

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

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

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

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

「缺陷分析很重要,但是研發同學都太忙了,我們兩個月集中做一次怎麼樣?」
別那麼緊張——及時才是最節約的方式。要從忙碌中解放出來,每次花 15 分鐘,做一次有效的缺陷分析,時間已經妥妥的啦。

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

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

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

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

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

我們的方案是:

1. 把結對分析作為制度

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

2. 團隊定期討論學習

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

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

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

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

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

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

**如下:

void releaseresources (resoure_id)

}

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

「原因是什麼?」

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

「ok。需求分析是問題,這是乙個改進點。——但是更重要的:最後發現這個問題的最直接的機會點是哪個時間點?」

「寫**的時候。」

「寫**的時候我們注意到這個問題了嗎?」

「注意到了啊,所以寫了 log,但是沒仔細想應該怎麼處理。這說明我們對這段**的職責定義不清晰。」

「也許我們可以在程式設計規範中加入一條:出現異常場景時不應該只記錄 log,而應該和負責人澄清場景和處理方案。在未來,當出現了僅僅出現寫錯誤 log,但是沒有其他處理的時候,我們就能注意到這一點。」

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

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

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

1. 短期的行動

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

2. 長期的規則

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

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

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

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

通過缺陷分析,我們可以形成如下的產出:

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

作者 | 嵩華

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

作者 嵩華 軟體開發中的缺陷隱含著極高的價值,但是許多組織都僅僅忍受了缺陷帶來的成本和後果,卻讓價值白白溜掉了。缺陷的價值是其觸發的學習和成長的機會。把握缺陷帶來的學習機會,可以快速提高組織的能力,未來的缺陷更少,成本更低,更容易成功。但同時,有效的缺陷分析和跟蹤行動需要有效的方法和相應的組織的支援...

如何提交高質量的缺陷報告單?

關於如何提交高質量的缺陷報告單,本人總結了如下幾點 1 缺陷的概要描述要清晰準確,要使相關開發負責人員能夠一目了然問題是什麼。2 乙個完整的缺陷報告單,必須包含其必要的元素資訊,例如 概要描述,缺陷發現人,測試環境,瀏覽器,缺陷重現步驟,嚴重等級,指派人,所屬功能模組等等,必要元素資訊必須描述全面清...

SEO高質量的偽原創怎麼寫?

所謂 內容為王,外鏈為皇 已經被人們當成了戲言,但這句經典之語在seo界依然會長久的屹立不倒。內容為王 講到的就是內容了,那麼,我們要怎麼才能寫出高質量的內容即可以討得度娘的芳心,又可以俘獲目標使用者呢?不管是對於站長還是對於乙個seoer,大家都很清楚,永遠的原創基本不可能,而度娘的喜新厭舊又是出...