標籤：
聲明：本文檔的內容主要來源於書籍《軟體調試修鍊之道》作者Paul Butcher，屬於讀書筆記。歡迎轉載！
--------------------------------------------------------------------------------------------
缺陷優先
如何使缺陷修複與軟體開發相結合？
如何估計缺陷修複花費的時間？
如何確保項目不會陷入《人月神話》中所描述的無數缺陷修複的焦油坑中呢？
- 缺陷優先
- 測試、代碼審查、讓使用者使用軟體要貫穿於整個開發過程中
- 缺陷修複要由於其它任何事情
- 早期缺陷修複可以大大降低軟體啟動並執行不可靠性，並估計修複上所需要的大概時間以調整你的測試計劃，後期修複只會積累技術債務，也不知道何時能修複他們並結束項目。
- 品質低下具有傳染性，因此要沒有破窗，軟體開發與維護，是一個持續與熵抗爭的過程
2.調試的思維
- 調試首先是一種心理活動，要保持健康的調試心態。天真的說，“沒有破窗”可以被理解為只有絕對完美的情況下才能實現。任何參加過軟體開發的人都知道，缺陷不可避免，無論多麼努力，總會有遺漏，如何解決這個問題？
- 最有效思維模式是務實的零容忍策略，非常接近於零，但是用務實的心態去實現，雖然我們遠遠做不到完美，但是可以用正確的方式無限的接近它。
- 採取無破窗策略時，要分清是缺陷還是特性，缺陷是無意識行為，其它都是特性，對於客戶來說二者可能一樣，但是軟體開發人員要分清，並且要明白特性就是軟體按照設計啟動並執行，問題沒有缺陷那麼嚴重。
3.自己解決品質問題
- 沒有快速修複缺陷的靈丹妙藥，唯一可靠的方法就是修複所有缺陷。 停止開發有缺陷的程式，構建實驗，觀察結果
- 把不乾淨的代碼從乾淨的代碼中分離出來，如果沒有足夠的時間修複它，那麼就先阻斷它，這種方法的一個變化形式是採用“沙箱模型”來解決問題模組。
- 錯誤分類，定期更新缺陷資料庫，並保證新建立項目具有合理的優先順序。
- 缺陷閃電戰，即在一天、一周或者一個時期內，除了修複缺陷不做其它任何工作，但是要謹慎使用，期間一長，很容易讓人疲憊，並累垮每一個人。
- 專項小組，是閃電缺陷戰的變形，讓一個小組在有限的時間內聚集在一起解決特殊的品質問題。
4.修複已經發布的軟體時，要集中精力減少風險
- 一個真正的修複可能涉及大範圍的軟體重構，深層次的軟體體系變化，在缺少發布過程的正常檢驗和各環節平衡的前提下，很難確定其帶來的連鎖反應，最終使事情變得更糟而不是更好。因此實施一個補丁時，治標不治本可能是一個更好的選擇。
- 不要以為修複程式試一次修改就疏忽大意，要注意與這樣的修複產生關聯的潛在問題，因此要儘可能多的檢查。
- 在開發版經曆完整的發布周期時，要得到一個完整的、解決根本的修複。
5.向後相容
- 確定代碼本身的修複不會引起相容性問題，迴歸測試可以查明向後相容性問題
- 解決相容性問題，如果確認導致相容性問題，那麼需要按照下面的選擇
- 提供遷移辦法
- 實現一個相容模式
- 提供預警
- 不修複缺陷
6.海森堡缺陷
- 如果在調試器下運行軟體，嘗試將插樁直接加到源碼中。
- 海森堡缺陷依賴於某些不確定性因素，這本身就是一條線索，把你的任務變為尋找某種方法來收集你所需要的資訊，這種方法對軟體影響極小，保證不會改變它的行為
- 修複該缺陷的唯一辦法就是比平時更仔細些，確保你真正瞭解潛藏的根本原因。
- 在未瞭解問題本質前，不要假設你已經修複它了。比如缺陷是由一個未出生的變數引起的，那麼要弄明白未出生的變數如何引起你觀察到的行為？將其初始化為壞值，你能看到預期的結果嗎？ 效能缺陷 尋找瓶頸，是哪個特定地區的代碼限制了整體效能 準確效能分析
7.嵌入式軟體
- 調試嵌入式軟體是非常棘手的，不是它錯綜複雜，而是它所在的運行環境。
- 利用嵌入式調試工具，可以通過網路電纜進行遠端偵錯，或者通過JTAG,SW線上調試,其中挑戰之一是軟硬體並行發展，通常修複一個硬體問題比解決軟體問題更難。
- 提取資訊的痛苦過程，一個LCD、LED、串口等手段當做通訊通道往往就夠了，雖然並不方便，但是它是可能的。
- 利用邏輯分析儀作為軟體的調試工具，解決時序錯誤！
8. 第三方軟體的錯誤
- 不要太快去指責，第三方也只是代碼，也會包含缺陷，首先要懷疑自己的代碼。
- 如果確信第三方代碼存在缺陷，那麼出了提交錯誤報表並等待解決，別無它法，最好是短期內擱置問題。
- 開原始碼，很多開源項目只獲得了有限的關注，因此其開源不意味著調試的結束。
- 開源社區的一個偉大之處是，為我們提高了高品質、免費的軟體，往往高品質的支援人員也是免費的。因此要學會有效尋求協助。
<讀書筆記>軟體調試之道 ：從大局看調試-零容忍策略
