怎樣消滅BUG
摘要：提高缺陷響應力有助於提升軟體品質，如果我們不能把Bug扼殺在搖籃裡，就儘快幹掉它，把它變爲一個happy accident吧！
太長不讀版
Why do programmers prefer dark mode？
Cause light attracts bugs.
正文
Bug從哪兒來？
對任何人來講，搞清楚「我是誰、我從哪兒來、我要到哪兒去」都不是件容易的事情。對Bug來說也一樣。
Bug從哪兒來，如果這裏的Bug是指單詞的話，問的就是這個詞是怎麼來的；如果是指詞義的話，Bug這個詞很多種詞性，放在這裏應該是個名字，名詞的Bug有三種解釋，臭蟲、故障和竊聽器。如果我們不指明上下文的話，讀者可能會按照自己的背景去解讀這句話，顯然對於生物學家、碼農和間諜來講，對這句話的理解是完全不同的。
邏輯語言是有限的，而現實世界是無限的。佛系青年莊周說：「吾生也有涯，而知也無涯。以有涯隨無涯，殆已！」，什麼意思呢？就是說軟體是不可能沒有Bug的。軟體是對現實世界的抽象，以有限的軟體邏輯去抽象擁有無限可能的現實世界，必然會有不match的情況，於是便有了Bug。
好，看上去我們已經達成了共識，軟體不可能沒有Bug。對於這句話，以發現Bug爲己任的QA們並不買賬，他們會把畢生的精力投入到讓Bug數無限趨近於0的測試活動中去。那麼，如果說我們不可能窮盡測試去找出軟體中所有的Bug，我們該做些什麼才能 纔能讓Bug少一點呢？讓我們先來研究Bug是如何產生的吧。
Bug產生的原因多種多樣
想象一個典型的場景，QA同學找到Dev提一個Bug，可能收到的回覆 回復有哪些呢？
- 「Sorry，打錯了。」
- 「我去，Copy忘改名了！」
- 「這是哪個XX動了老子的程式碼！」
- 「哦我週末沒事重構了一把，忘了跟你說。」
- 「這塊功能從我來公司就是這樣的。」
- 「在我這兒是好的呀，你環境問題吧？」
- 「這不是Bug，這是designed so，我們找BA去。」
- 「Story裡沒寫呀，我不知道。」
- 「靠，這個case太corner了吧，真想不到。。。」
我們來把這些回覆 回復歸歸類，就能得到Bug是從哪兒來的了。如下圖：
基於我們上面說的「現實世界是無限的」，所以這個圖現在不是完備的，以後也不會。（我能說這個圖的精髓在於省略號嗎？）就像專案上經常做的「Bug Root Cause Analysis - 缺陷根因分析」，我們試圖用一張圖窮盡Bug產生的原因，一個維度不夠再加一個維度，而這個圖卻遲遲出不了終版，估計以後也不會有，但這並不妨礙大家追求完美軟體的心。
消滅Bug v0.1：加測試 & 提升程式碼品質
企圖從所有原因上堵死Bug這條路看來走不通，有的同學說了，我不想知道Bug是怎麼來滴，我就想知道Bug是怎麼沒滴。老生常談的是增加測試和提升程式碼品質。我們來看一下，不管是測試左移鼓勵測試早介入，還是測試金字塔鼓勵測試下沉，都說明了增加測試是一個有效的方法。但是，就好像TDD不是銀彈一樣，如果你沒測到呢？我們再來看一下，Code Review和結對程式設計確實能提升程式碼品質，但是，如果大家都沒測到呢？如果Bug就是產生了呢？如果重大Bug就是上了生產呢？
我們再來討論「提升程式碼品質」，關於這一點我是存疑的。首先說出發點是好的，確實需要提升程式碼品質，但是我不認爲這是一個完全有效的消滅Bug的方法，相反的，「只要開發人員好好寫程式碼，就能消滅Bug」，就好像說「只要我們付出努力，就能走向人生巔峯」一樣蒼白。提升程式碼品質非一朝一夕之功，這是其一。其二，就算是技能再好的程式設計師，只要是人，就有可能犯低階錯誤，而據統計低階錯誤佔Bug產生原因的比例可是不低的。讓我們走出完美世界的幻想，面對現實吧。
消滅Bug v0.2：提升缺陷響應力
就像大禹治水疏而不堵，我們換個角度來考慮一下，萬一重大Bug上了生產，如果能飛速解決掉，使用者甚至毫無感知，那麼也算是及時止損了。如何能更快的解決Bug呢？經驗告訴我們，如果修復一個Bug總共花了兩天，那麼定位Bug大約會花一天半，大部分的時間都會花在「找Bug」這件事情上。如果能縮短「找Bug」的時間，就能提高我們的測試效率，提高我們的缺陷響應力（缺陷響應力這個詞沒見過吧，現編的）。
何爲高缺陷響應力？分爲三個含義，一是能在開發階段儘早發現問題，二是上線後能快速定位分析問題，三是生產環境有問題能及時反饋。
爲了快速發現問題，我們提倡小步提交，提升自動化測試覆蓋率，測試掛了CI很快就反饋了，有問題的程式碼不會被部署上去，況且變數少也好排查。這就是爲啥QA總在孜孜不倦的提醒大家「補測試」。當然了，就算測試覆蓋率達到99.99%，也不能保障完全沒有Bug，所以我們還有其他的實踐來作爲補充。
爲了快速定位分析問題，我們提倡日誌監控和收集，提倡測試右移至生產，引入更多方便有效的工具幫助我們快速定位。舉個例子，很多專案都會建立完善的監控和告警機制 機製，上線後持續監控，以便於發現重大缺陷後馬上修復卷動部署。持續監控是一方面，而另一方面，我們還要保證監控到的日誌包含需要定位問題的有效資訊，這就要求我們建立完善的日誌規範，嚴格遵守日誌分級，日誌描述內容應該和程式的行爲保持一致。怎樣輸出有效的日誌是另一個話題，在此不展開討論。
爲了保證問題的及時反饋，我們也需要建立快速的響應機制 機製。在某些對實時正確性要求比較嚴格的行業，如實時交易系統等，可以通過卷動部署和切換災備伺服器的方式來快速響應重大線上事故。而對於一些業務較爲複雜的大型管理系統而言，建立分級的響應機制 機製必不可少，針對不同嚴重性的問題，可以採取不同的響應措施，確保重大問題的及時反饋。
這些專案常用的敏捷實踐不再贅述，但需要強調一點，即測試工作的本質——控制變量。任何時候，先想清楚再做事情總是不差的，在遇到問題時，先儘可能的縮小排查範圍，是事半功倍的關鍵。
總結一下，提高缺陷響應力有助於提升軟體品質，如果我們不能把Bug扼殺在搖籃裡，就儘快幹掉它，把它變爲一個happy accident吧！（爲啥happy？因爲Bug修了呀）面對這些惱人的Bug，希望我們不論身處什麼角色，都能保持一份樂觀向上的積極心態，就像本文的小標題一樣，永遠有持續改進的上升空間，因爲我們必將永遠行進在無限逼近完美的道路上。
最後送一個段子，皮這一下挺開心。
要想Bug少，需求關把好；
場景考慮全，使用者體驗好；
編碼需細心，邏輯知多少；
Copy一時爽，忘改不得了；
測試需有效，環境管理好；
缺陷響應快，使用者都說好。
文/ThoughtWorks於曉南