為什么要編程？因為代碼沒在那里。創造一個世界是如此讓人著迷，Linux 的創始者 Linus 這樣表述對編程的喜愛之情：

每個熱愛編程的人都在編寫代碼的過程中享受著創造的樂趣，但是，伴隨著編碼的快感，bug 總是如影隨形，開發無止境，bug 隨身行。bug 是每個程序員沒法繞開的障礙，它們就在那里，修復一個，增加一個，似乎永不減少，永遠存在。


遭遇 bug 的時候，理性的程序員會說：這個 bug 能復現嗎？
自負型：這不可能，在我這是好好的。
經驗型：不應該，以前怎么沒問題？
幻想型：可能是數據有問題。
無辜型：我好幾個星期都沒碰這塊代碼了！
樂觀型：只需要改一行代碼，不會影響其它程序的。
實踐型：你重啟一下服務試試。

無論你是哪種類型的程序員，遭遇 bug，內心都是崩潰的，尤其是產品經理或測試人員在使用或測試產品的過程中抓到你的一個 bug 之后那種如獲至寶的表情和歡呼聲，會讓我們的心情久久不能平靜。于情于理，防患于未然，減少編程中的 bug，對產品和程序員，都是最好的結果。

能不能一次編寫出沒有 bug 的程序呢？一般來說，并不能，除非你寫一輩子 Hello World。我見過一些天才的程序員，他們差不多能做到這一點。接到任務之后，思考，冥想，在筆記本上畫出數據結構或某個算法片段，腹稿打的差不多了就開始編程，用 Vim、Emacs 或 IDE 工具，大部分時候能夠一氣呵成，然后構建代碼，構造測試數據，運行程序，在反復調試中修復幾個編程過程中沒有考慮到的問題，就可以提交到代碼庫了。他們的代碼交給測試和其他開發者，少有人能挑出 bug，因為他們對代碼有敏銳的感覺，能夠在別人忽略的地方發現代碼的壞味道，并給出巧妙而優雅的解決方案。他們是天生的代碼創造者，這樣的人往往效率高而且少有錯誤，以至于會被一些平庸的團隊忽略，因為技術領導總是會下意識的去關注那些最容易出事的環節，但這些人才是團隊真正的脊梁，不是那些四處救火者。如果你擁有這樣的程序員，就算撿到寶貝了，要好好珍惜。

我不是天才的程序員，但在年輕時大量產出代碼的時候，差不多也能做到類似的效果。沒什么好的辦法，只能下笨功夫，我會在編碼之前盡可能把所有的可能性都想清楚，然后認真做好設計。我常常在工作時間完成代碼的編寫，下班后帶著筆記本回家逐行 Review 自己的代碼，對著設計圖檢查是否處理了各種異常和邊界條件，并先于測試人員對自己的代碼進行白盒測試和黑盒測試。另外，在編程方面我奉行不要在同一個地方摔倒兩次的原則，每次自己程序出現的 bug 案例，我都會記錄到 bug 庫里，檢查代碼的時候逐一對照，確保不會犯重復的錯誤。

可能年輕的時候自尊心比較強，我難以忍受自己的程序被別人找出 bug，于是偷偷花費了兩倍的時間來保證代碼的質量，以至于團隊的人認為我一次就能編寫出高質量的代碼。現在看來，我當時是個錯覺制造者。

所以，減少 bug 的第一步，是提升自己的程序員素養，努力不給自己和別人找麻煩。

另外，團隊協作也很重要，前期的技術方案和設計評審、代碼審查，對減少一些重大的錯誤和弱智的 bug 都非常有好處。

與幾個有經驗的程序員一起評審一個技術方案，常常會發現一些重大的問題，比如為什么用緩存，為什么做持久化，高并發下怎么應對，這部分設計支持線程重入嗎，這個循環為什么設置成10分鐘，這個超時設置為什么是60秒，傳輸協議加密了嗎，等等。很多方案可能會僅限于解決當前的問題，但有經驗的程序員卻能透過時間的重重迷霧，發現這個方案在未來某個時間點可能爆發的問題。這就是評審的力量。

技術方案和設計評審一般是先于代碼的，開始編寫代碼了，Code Review（代碼審查）就可以提上議事日程了。國內很多團隊的技術人員內心是抵觸代碼審查的，他們常常想，在這個國家我們已經被審查的夠多了，就不要再自己審查自己了，然后很多 bug 就產生了。

我和 Google、Facebook、Twitter、Airbnb 的中國工程師討論過 Code Review，他們覺得沒有代碼審查是不可思議的。在這些公司的研發流程里，Code Review 是必不可少的一個環節，只有別人幫你做了 Code Review 并在代碼上「打了戳」，你的代碼才能進入 Code Base。在 Facebook，如果你 Review 了別人的代碼，如果那個人休假了，你就要接手他的代碼，出了任何問題都要唯你是問。

事實上，Code Review 才是真正的白盒測試，沒有經過代碼審查，僅憑測試很難保證代碼質量。測試通過了但沒有經過代碼審查的代碼仍然會出各種問題，這樣的案例比比皆是。只有當另外一個人讀了你的代碼，并且表明能看懂時，這些代碼才有真正有了鮮活的意義。代碼審查的意義就是，在你的代碼庫合進代碼庫之前，至少有一個人讀過你的代碼。

很多人在做代碼審查之前會調研大量的代碼審查工具，就像一個人在跑步之前，要先準備好跑鞋、襪子、壓縮褲、壓縮上衣、鼻貼、眼鏡、口罩、導汗帶、魔術頭巾、各種手表、冷卻噴霧、肌內效貼布……然后一個月過去了，你問他跑了幾次，他會很扭捏的告訴你，髕骨帶還沒有到！

沒有工具一樣可以做代碼審查，你只需要偏轉身體，在另一個程序員不忙的時候拍拍他的肩膀說，「來，看看我的代碼，你能看懂嗎？我準備把它們提交到代碼庫里」。然后闡述你的思路，傾聽他的建議，并根據這次討論的結果決定，是修改一下，還是繼續提交到代碼庫。

不要小看這短短的20分鐘，它可能會幫你避免的一些隱藏的和弱智的 bug。

很多團隊都是因為代碼審查過程或工具過于復雜放棄了Code Review，典型的因噎廢食，其實使用 less、diff 和 git 等工具，基本上就可以做一次完整的代碼審查了。如果你過于依賴工具和過程，那說明你并沒有抓住問題的核心。

寫了這么多，如何減少編程中的 bug 呢？不難，也不容易。對內，努力提高自己的程序員素養，不去浪費自己和別人的時間。對外，重視團隊協作，進行方案評審和代碼審查。做到這兩點，你會發現，代碼中的 bug 會越來越少的。

沒有 bug 的代碼，才是好代碼！

本文來自：池建強的博客