[[142581]]

當某些功能沒有按預期運行時，bug 就出現了。一次 bug 修復基本上是給現有代碼打一個補丁，它應該解決當前問題，以確?！冈摴δ堋拱搭A期運行?？墒牵@個補丁修復了一個地方，卻常常破壞了很多地方。我相信有必要時不時地拒絕 bug 修復，并要求其作者重新制作補丁，以保護項目避免遭受更大的問題。根據我的經驗，對于這種拒絕，存在著一些正當理由。

[[142582]]

《***犯罪（El Crimen Perfecto）》，導演：Alex de la Iglesia

它降低了代碼覆蓋率

這是非常常見的情景：在某個地方做了修改之后，單元測試在其它地方失敗了。bug 被修復了，但是一些可能不相關的單元測試開始報告失敗。由于壓力或僅僅因為我們的懶惰，我們沒有修復它們；我們只是刪除了測試、或將它們標注為臨時的「跳過」。問題被解決了，構建是干凈的，那么合并該補丁，收工，對嗎？錯！

即使我喜歡盡可能的偷工減料，但是對于這種問題，我不推薦你那樣做。

單元測試的存在恰恰是為了防止我們在面臨壓力時去破壞代碼。

很明顯，存在著一些情景，比如單元測試錯了，我們不得不刪除它們。對于這種情況，記得要創建新的單元測試。

還有一些情景，比如 bug 必須盡快修復，保證系統線上運行，而修復所有單元測試將花費 1 個小時。這種情況強烈預示著，你已經處于一種可怕的潛在情景，那就是產品中的測試覆蓋率。毫無疑問，我們不得不做出修復，并在一段時間后讓測試通過。但是，對于這種情況，要確保團隊在修復該 bug 之后的下一個任務就是糾正那些不好使的單元測試。我推薦閱讀 Michael Feathers 編寫的《修改代碼的藝術》，本書為該主題提供了正解。

Michael Feathers 編寫的《修改代碼的藝術》

它不會重現問題

有時候整個系統掛掉，僅僅是因為某行代碼里的一個小拼寫錯誤。明顯的 bug 修復就是刪除這個拼寫錯誤，如果我們關心項目質量，這就不是項目期望我們做的操作。問題不在于拼寫錯誤，而在于缺乏單元測試，單元測試在部署階段是可以捕捉到這個錯誤的。

真正問題在于，測試代碼覆蓋率在代碼的這個部分是缺失的。單純地刪除拼寫錯誤，無助于整個項目。而且，我們在傷害它——我們正在掩蓋真正的問題。

不管問題多么小、不管其表現形式是多么地迷惑人，bug 修復必須包含可以首先重現該 bug 的額外測試。沒有這樣的測試，所謂的 bug 修復只是在浪費項目的金錢。

進一步講，沒有重現問題的單元測試，就無法保證 bug 修復不會帶來更多的 bug。我甚至敢說，我們的 bug 修復越多，引起的熵【注1】就越高。減少這種不確定性的唯一方式就是用單元測試覆蓋代碼。沒有測試，bug 修復將給代碼庫帶來更多的無序。

它太大了

bug 修復不是功能；它們必須小而專注。在修復 bug 時，引入了某些重構，這是程序員自我陶醉時經常要犯的錯誤。結果，補丁大得難以理解。我不是反對重構；重構對于項目非常重要，屬于積極的舉動，但要在 bug 被修復、合并之后，專門來做重構。

請在修復 bug 的時候，不要重構代碼！

創建一個新的單元測試，重現 bug，并提交。在現有的代碼庫里修復 bug，不管它是多么丑陋。創建新 bug，要求團隊改善丑陋代碼庫的狀況。如果感興趣，就把這些 bug 分配給你自己。或許其他人只是對修復它們以及重構代碼感興趣。不過所有這些都會在其它的 pull request 里發生，也帶著新的代碼審查和新的合并。

修復那些糟糕的代碼，和懶惰、不愿意沒有關系。這是一項紀律，比良好意圖更加重要。

它不只解決一個問題

每次總是修復一個問題——就這么簡單，沒有例外。當一個 bug 修復的補丁包含了修復多個問題的代碼修改時，就很難理解哪個問題被測試到了，哪個是可重現的、以及它們彼此有何關聯。把多個 bug 修復整合到一次 pull request 是一種非常糟糕的實踐。

不管這次修復多么簡單，要確保它和其它修復分開。逐個審查代碼、測試以及合并。這也增加了追溯代碼修改的便利性，很容易理解誰做的此次修復、誰審查的代碼、以及什么時候被合并（和部署）。

• 注1：在信息論中，熵是接收的每條消息中包含的信息的平均量，又被稱為信息熵、信源熵、平均自信息量。這里， 消息代表來自分布或數據流中的事件、樣本或特征。（熵***理解為不確定性的量度而不是確定性的量度，因為越隨機的信源的熵越大。）https://zh.wikipedia.org/wiki/%E7%86%B5_(%E4%BF%A1%E6%81%AF%E8%AE%BA)