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

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