昂貴的品質

2022 年 10 月 8 日
筆記
軟體工程

「To err is human」

在過去相當長一段時間內我都在一個負責進行項目維護的團隊內工作。團隊的特殊之處在於我們從來不開發新功能而是負責解決每天上報的線上問題。這些bug 無奇不有，從無法打開頁面到數據奇怪丟失，麻木早已經替代焦慮成為了我們面對 bug 時的主要情緒。

但我時不時地抱怨依然是：為什麼 bug總是在發生。

缺陷早已在豐田生產系統（ToyotaProduction System）中被標註為浪費之一。沒有人希望看到 bug，我們不想，客戶更加不想。但我們似乎都不願承認的一個事實是 bug是程式碼的副產品而已。如果我們選擇接受編碼不過是人思維活動的一種形式與思考無異，那我們也就必須接納人性的缺陷在程式碼中自然也不會缺席，恰如硬幣的正反兩面。

反過來說，如果你對 bug採取的是零容忍的態度甚至不惜把此寫入 KPI中，它也未必會帶來正面效應，因為自此開始，沒有人會願意重構，沒有人會願意引入新的技術方案，道理非常簡單：改動越多風險越大——這是某年發生在我所屬團隊的一次親身經歷。

所以我們並非面臨的是 bug去或者留的選項，而是多與少的問題。

擺正品質

在 MoSCoW方法論的框架下，我們通常可以將功能的優先順序劃分為四類: Must Have, Should Have, Could Have 以及 Won』tHave，如果把品質也作為功能的一個維度選擇落入這四個區間之一的話，它一定不會在 Must Have 這個範圍內。因為人們既不會因為沒有 bug而選擇長時間地使用一款應用，也不會因為存在 bug而成為轉投它競爭對手的理由。我們必須承認這樣一個事實：品質永遠也不是商業的核心競爭力，這也暗示著：

品質缺陷是可以被容忍的
品質被分配得到的資源永遠是有限的。

前者並非我們的一廂情願，在互聯網產品的高性價比和快速迭代的商業邏輯下，用戶對產品品質的預期已經被規訓到一個非常「理想」的狀態

而後者更為關鍵：我們應該如何最大化利用有限的資源去提升品質？如果你所在的部門也有機會組建一支類似於本文開頭團隊，那不妨考慮一下這個建議：用資源換取更多的人員加入這支團隊怎麼樣？

原諒我用一個粗俗的比喻來解釋為什麼這麼做行不通：我們換來的只是擦屎的速度，對造屎的人產生不了任何影響，效果甚至會適得其反：考慮到總有人為他們收拾殘局，我們的善後工作做得越好，他們越是會肆無忌憚。

但這是當下大部分公司的現狀：如果線上問題激增，是不是QA 工作不到位？我們似乎傾向把編碼和測試的界限劃分得一清二楚，從人員到職責到工序都是如此。而品質問題從編碼中來，卻想從測試中尋找解決之道，這與刻舟求劍無異。

鋪墊了如此之多我想表達的觀點依然是老生常談：品質內建，以及最近幾年我們常常提倡的測試左移。至於什麼是品質內建和測試左移，並不在這篇文章的範圍內，你在網上可以找到大量的專業文章來介紹他們

品質的成本

現在我們必須回答一個核心問題：誰該對品質負責？最官方的答案是每個角色，我們可以列舉出產品經理沒有全面地對功能做驗收，QA沒有把控好品質關等等。但假定此刻我們必須指定一人將他五花大綁起來祭天，為的是有人需要為上一個讓人焦頭爛額的bug 負責，程式設計師絕對是不二之選。

但程式設計師死也不會瞑目的。

如果你是團隊經理，你發現上個月線上問題數量增加了一倍，於是你衝到你的工程師團隊工位前怒不可遏地沖他們吼道：我希望這個月的線上問題不超過個位數！你覺得他們能做到嗎？

我想說的是，品質不是「希望」的結果，它是付出的收穫。關鍵在於你願意用什麼去交換。

提升品質的訣竅一點也不神秘。口口相傳的各類業內實踐便是最好的靈丹妙藥，比如重構、程式碼評審、結對編程、流水線集成等等。我們不妨就以單元測試為例，看看我們需要付出多大的成本

首先時間便是一筆可觀的支出。以我所在的項目為例，我們為前端React 組件編寫單元測試的時間幾乎與開發功能的時間相同。注意這還是在沒有追求覆蓋所有的邊界用例，以及沒有追求 100%的測試覆蓋率的情況下。另外當我們編寫的程式碼導致之前編寫的關聯測試無法通過流水線時，去查找失敗的原因以及修正這些錯誤也是隱形時間。

其次在我看來最難以逾越的障礙在於對工程文化的重塑。對下要強調保證程式設計師去寫、關注、修復的紀律；對上要爭取理解和空間來輔助這些實踐，單拎出來任何一件事推動起來都不簡單。工程實踐天然具有一種反商業活動的特性，它很難被量化、難以一針見效。沒有人敢拍著胸脯說在xx 天之內或者當測試覆蓋率至少達到 xx 水平之後 bug 數量會降至 xx。我們都不否認它會變得更好。諷刺的是實踐帶來的「負面」效應是立竿見影的：工程團隊的交付速度變慢了。

測試的部分好處還來自未來，比如它能增強我們重構程式碼和變更架構時的信心，防止舊功能無意被新功能破壞。但我依然無法保證你的收益會何時何地有幾倍於付出的到來。

於是現狀變成了一方面可見的迭代速度變慢，另一方面成本的付出看不到收益，品質就自然值得被犧牲。

在提升品質的過程中我們解決的不是個體問題而是工業問題，細想這是很難的：一個團隊中不同成員的能力不同背景不同，但我們卻要設法讓它們的產出品質處於某個水平之上。

還債

聽上去我們只能義無反顧去相信（take a leap of faith）某些實踐能夠幫助我們提升品質，且付出的收益是不確定的。但換一個角度想，我們只是在做一些本該做好的事情而已，用戶的寬容讓品質變得可有可無。

我不否認有時候快比好更重要，只不過當有一天品質變成我們無法再忽視的問題時，別不知所措地想不起來品質是在哪裡搞丟的。

你可能會喜歡

Tags: 軟體工程