作者 | 李光毅

 “To err is human”

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

但我時不時的抱怨依然是：為什么 bug總是在發(fā)生。

缺陷早已在豐田生產(chǎn)系統(tǒng)（Toyota Production System）中被標注為浪費之一。沒有人希望看到 bug，我們不想，客戶更加不想。但我們似乎都不愿承認的一個事實是：

bug是代碼的副產(chǎn)品而已。

如果我們選擇接受編碼不過是人思維活動的一種形式，與思考無異，那我們也就必須接納，人性的缺陷在代碼中自然也不會缺席，恰如硬幣的正反兩面。

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

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

擺正質量

在 MoSCoW 方法論的框架下，我們通?？梢詫⒐δ艿膬?yōu)先級劃分為四類: Must Have, Should Have, Could Have 以及 Won’tHave，如果把質量也作為功能的一個維度落入這四個區(qū)間之一的話，它一定不會在 Must Have 這個范圍內。因為人們既不會因為沒有 bug而選擇長時間地使用一款應用，也不會因為存在 bug而成為轉投它競爭對手的唯一理由。我們必須承認這樣一個事實：質量永遠也不是商業(yè)的核心競爭力，這也暗示著：

• 有些功能缺陷是可以被容忍的
• 質量被分配得到的資源永遠是有限的。

前者并非我們的一廂情愿，在互聯(lián)網(wǎng)產(chǎn)品的高性價比和快速迭代的商業(yè)邏輯下，用戶對產(chǎn)品質量的預期已經(jīng)被規(guī)訓到一個非?！咐硐搿沟臓顟B(tài)。 

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

原諒我用一個粗俗的比喻來解釋為什么這么做行不通：

我們換來的只是打掃的速度，對制造垃圾的人產(chǎn)生不了任何影響，效果甚至會適得其反：考慮到總有人為他們收拾殘局，我們的善后工作做得越好，他們越是會肆無忌憚。

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

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

質量的成本

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

但程序員死也不會瞑目的。 

如果你是團隊經(jīng)理，你發(fā)現(xiàn)上個月線上問題數(shù)量增加了一倍，于是你沖到你的工程師團隊工位前，怒不可遏地沖他們吼道：我希望這個月的線上問題不超過個位數(shù)！你覺得他們能做到嗎？

我想說的是：

質量不是「希望」的結果，它是付出的收獲。關鍵在于你愿意用什么去交換。

提升質量的訣竅一點也不神秘?？诳谙鄠鞯母黝悩I(yè)內實踐便是最好的靈丹妙藥，比如重構、代碼評審、結對編程、流水線集成等等。我們不妨就以單元測試為例，看看我們需要付出多大的成本 

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

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

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

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

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

還債

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

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