聲明：本文檔的內容主要來源于書籍《軟件調試修煉之道》作者Paul Butcher，屬于讀書筆記。歡迎轉載！

--------------------------------------------------------------------------------------------------

有時盡管修復設計的是一個孤立的代碼區，但你還是需要大局觀，在修復缺陷之后花時間反思一下！

一旦確定了錯誤的來源，就可以采取措施避免它再發生！有些情況下，只不過是告訴你未來在在這一方面要更加小心！

在事后要反思并總結，尤其你發現了錯誤的模式只發生在特定的點或者特定的原因下時。極少數情況下，需要對自己敲響警鐘！

?

1、問五個為什么，總體來說大部分情況下都能對你有幫助，比如：

• 軟件崩潰了，出錯了，為什么？
• 該代碼不處理數據傳輸過程中的網絡故障，為什么？
• 沒有專門檢測網絡故障的單元測試，為什么？
• 最初的測試人員并沒有意識到并創建一個這樣的測試，為什么?
• 我們的單元測試沒有考慮到軟件故障，為什么？

可能很快就會得到，我們在原先的設計中沒有考慮到軟件故障這個問題癥結，也可能有很多步驟。

2、根本原因分析

• 需求 需求是否完整、清晰并且未被誤解？。
• 設計 在架構或者設計中是否存在疏漏，是我們沒有考慮到還是沒有正確的按照設計來做。
• 測試 對代碼的測試是否達到了足夠的覆蓋率？或者測試本身就有問題呢？
• 構造 是開發人員寫代碼是犯了一個很簡單的錯誤，或是誤解了某些基礎技術？

3、和同事交流問題注意事項

讓同事知道他犯錯了這件事情可能比較危險，一方面這個有價值的信息需要讓同事知道以免其重蹈覆轍，另一方面，由于程序員不善交際溝通，可能由于口無遮攔把事情搞砸，所以你的善意可能得不到友好的回應，但是是需要做一些有益的事情。

• 首先最重要的，要有正確的出發點，不要只是為了得到自己的優越感。
• 在交流前，要三思并換位思考，如果自己犯錯了該怎么辦？
• 要清楚知道其性格特點！
• 避免妄作評判，不要說“你應該怎樣”，而可以說“我們可以怎樣”
• 要有建設性 要記住你也可能說錯了!

4、關閉循環

如果你著手的項目有一套自己的規范：比如編碼規范、測試規范、文檔規范、報告/跟蹤過程、設計指南、性能需求。當修復缺陷時，你是否需要更新最終用戶文檔作為修復記錄？或為下一個版本更改日志？或者把它交給QA部門？該工作是否需要對特定客戶或者項目進行跟蹤（涉及到返修甚至召回）？

總結

以上是生活随笔為你收集整理的读书笔记软件调试之道 ：问题的核心-如何修复缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。