.NET開發(fā)人員調試策略

目 錄
第1章 調試簡介 1
1.1 明確問題 1
1.1.1 三思而后行 2
1.1.2 是否值得這樣做 2
1.1.3 提高調試技能 3
1.2 .NET新增的調試特性 4
1.2.1 內存問題不再出現 4
1.2.2 語言無關性 5
1.2.3 遠程調試和跨機調試 6
1.2.4 從進程中分離 7
1.2.5 ASP.NET 7
1.3 其他內容 8
第2章 調試過程中的6點建議 9
2.1 在檢查Bug時，不要忽視在此之前出現的任何Bug 9
2.2 不要忘記最終目標是讓程序正確執(zhí)行-- 修正Bug只是手段，
并非最終目的 11
2.2.1 當目標依賴許多子目標，而這些子目標又依賴更多的子目標時 13
2.2.2 當進行下一步很困難時，可尋找一種簡單的辦法 13
2.3 當代碼在一種方式下正常運行，而在另一種方式下出現故障時，
應將注意力集中在導致代碼出現故障的方式上 14
2.3.1 將注意力集中在不同點上 15
2.3.2 當一些程序以某種方式運行時 16
2.4 在沒有合理的證據時，不要懷疑問題出在硬件、API或OS上 17
2.5 在一些測試計算機上不要安裝調試工具-- 以免發(fā)生異常循環(huán) 19
2.5.1 在非開發(fā)環(huán)境下檢驗代碼的工作情況 20
2.5.2 確保能夠在客戶站點上調試您的產品 21
2.5.3 為您的團隊提供使用其他調試方法的實踐機會 22
2.6 編碼后，立即在調試器上逐步驗證所有代碼 22
2.6.1 忘記補充函數細節(jié) 23
2.6.2 發(fā)現處理錯誤的代碼隱藏著一個嚴重的問題 23
2.6.3 把修改代碼也當作一次測試，但是偶爾也應該檢查一下 24
2.6.4 錯過優(yōu)化代碼的機會 25
2.6.5 正確使用逐步調試 26
2.7 小結 26
第3章 制定計劃 28
3.1 蠻力調試 28
3.2 3個猜測 30
3.2.1 還是不相信我嗎？讓我證明給您看 31
3.2.2 構造一個測試案例 33
3.2.3 聰明地使用猜測 33
3.2.4 以前曾經見過與之類似的Bug嗎 33
3.3 手機問題 34
3.3.1 一旦做出假設，我們就很可能做蠢事 35
3.3.2 收集信息-- 到何時一切才能正常運行 36
3.3.3 推理實現細節(jié) 39
3.3.4 深入問題 41
3.3.5 決定性的問題-- 故障的根源是什么 43
3.4 小結 44
第4章 斷言調試 45
4.1 斷言 45
4.1.1 關于消息窗口的問題 46
4.1.2 使用斷言來啟動調試器 47
4.2 我經常驗證代碼，為什么還需要斷言呢 48
4.2.1 找到出錯點 48
4.2.2 斷言的部分優(yōu)點 50
4.3 .NET的調試和跟蹤類 51
4.4 積極地使用斷言 53
4.5 斷言性能瓶頸 55
4.6 不要斷言合理的情況 57
4.7 當不能簡單地使用斷言時 58
4.7.1 關于Windows服務的斷言 58
4.7.2 關于ASP.NET頁面和Web服務的斷言 59
4.7.3 關于遠程對象的斷言 61
4.8 使用TraceListener定制斷言 61
4.8.l 啟動定制的斷言 63
4.8.2 在服務中使用定制的斷言 64
4.9 小結 65
第5章 用日志調試 66
5.1 Printf調試 66
5.2 程序日志 67
5.2.1 日志中應該包含的信息 67
5.2.2 使日志易讀 71
5.3 .NET對記錄的支持 76
5.3.1 .NET中的偵聽器和開關 78
5.3.2 XML配置文件 80
5.4 Windows事件日志 82
5.5 小結 84
第6章 ASP.NET調試和SQL調試 85
6.1 ASP.NET和調試器 85
6.1.1 連接調試器 87
6.1.2 遠程調試 89
6.1.3 分離調試器 89
6.2 ASP.NET中的日志 90
6.2.1 ASP.NET跟蹤數據 91
6.2.2 啟用ASP.NET跟蹤 96
6.3 調試SQL存儲過程 100
6.3.1 直接逐步執(zhí)行存儲過程 100
6.3.2 在應用程序中調試存儲過程 102
6.3.3 SQL遠程調試 102
6.4 小結 103
第7章 調試遠程客戶站點 104
7.1 調試遠程客戶問題如此困難的原因 104
7.1.1 配置問題 105
7.1.2 您必須設計再現Bug 106
7.2 為什么要問我這么多問題？只要修正它不就行了 107
7.2.1 客戶的期望 107
7.2.2 為什么不能實現客戶的愿望 108
7.3 自動診斷實用程序 108
7.3.1 自動收集數據 109
7.3.2 診斷實用程序的設計決策 109
7.4 幫助您觀察客戶再現Bug的第三方工具 111
7.4.1 親眼觀察Bug 111
7.4.2 控制用戶的電腦 112
7.5 對于非常嚴重的Bug，可以讓開發(fā)人員參與技術支持工作 112
7.5.1 參與的人員越多，遺漏的信息越多 113
7.5.2 開發(fā)人員應該對客戶說的話 113
7.6 構建一個帶有更多日志的新版本-- 以及驗證它是否被安裝的方法 114
7.7 .NET的安全性 115
7.7.1 限制訪問 116
7.7.2 CAS的工作方式 117
7.7.3 處理SecurityExceptions 119
7.7.4 根據每個程序集授予權限 120
7.8 小結 122
第8章 多線程調試 123
8.1 多線程的概念 123
8.2 在調試器中查看線程 125
8.3 常見線程問題的原因 126
8.3.1 競爭條件 127
8.3.2 死鎖 130
8.3.3 資源匱乏 131
8.4 調試線程問題 133
8.4.1 調試競爭條件 135
8.4.2 調試死鎖 139
8.5 關于線程的思考 145
8.6 小結 145
第9章 錯誤跟蹤程序 146
9.1 需要錯誤跟蹤軟件的原因 146
9.1.1 您不知道的細節(jié) 147
9.1.2 錯誤跟蹤程序的概念 148
9.2 開發(fā)工作流程 150
9.2.1 常見的工作流程問題 151
9.2.2 執(zhí)行工作流程 152
9.2.3 處理工作流程中的反彈 153
9.3 搜索和報告 154
9.3.1 重復的PR 154
9.3.2 為解決當前Bug而從以前的Bug中查找線索 155
9.3.3 PR統(tǒng)計報告 156
9.4 和隊員交流 158
9.4.1 與其他開發(fā)人員合作 159
9.4.2 與測試人員合作 160
9.4.3 與技術支持部門合作 161
9.5 了解您的工具 162
9.6 小結 163
第10章 源代碼管理調試 164
10.1 源代碼管理介紹 165
10.1.1 使用Visual SourceSafe 165
10.1.2 允許開發(fā)人員協(xié)同工作 166
10.1.3 查看文件變化的歷史記錄 168
10.1.4 取回某一版本或者分離一個副本 170
10.1.5 防止意外刪除文件 171
10.2 用SourceSafe進行調試 171
10.2.1 用修改歷史進行調試 172
10.2.2 在分支管理中修正Bug 177
10.3 習慣于使用SourceSafe 182
10.4 小結 182
結束語 184