時常有朋友發郵件給我，說遇到了一個什么什么奇怪的問題，不知道是怎么回事，希望我幫忙看看。我基本上每天都會抽出或長或短的時間來回復這些郵件，不過也經常發現，其實許許多多的問題都完全是有能力自行解決的。在很多時候，我發現許多朋友還缺乏最基本的解決問題，分析問題的方式。其實我在平時工作中也會遇到各種各樣的問題，有時候甚至異常古怪，但是在仔細分析之下，往往都能解決。于是我現在打算談點解決問題的基本方式，希望可以幫到一些朋友。

如果您也有著方面的體會，也可以分享一下，即使是某個簡單案例也是很有幫助的。

要解決問題，首先是要定位問題，配合正確的推理方式，再仔細分析，“動手嘗試”很可能只是驗證推理是否正確的手段而已，其實大部分的情況都可以用思考來得出（或排除）。要定位問題，很重要的一點便是要把概念理清。很多朋友會輕視概念，認為那種“理論”有什么重要的，最關鍵的是“動手”——但殊不知概念能讓您的“動手”少走很多彎路。

例如，在一個問題出現之后，我往往會心想，這到底是“開發時”還是“運行時”的問題。我們在做開發時會用到許多概念，有些是“開發時”的概念，有些則是“運行時”的概念。我們開發會用到很多工具，Visual Studio是一個大工具，但是它也會把很多功能，如“編譯”等操作委托給外部的命令，VS只負責捕獲那些輸出而已。而在運行的時候，根本不會關VS什么事情。之前我寫過一篇文章，指出csproj，sln等等都是開發時的概念，它們離開了Visual Studio，MSBuild等開發工具之后，就沒有任何作用了。同樣，“項目模板”也是Vistual Studio才知道的東西，而運行的根本不會關心所謂的ASP.NET Web Site還是Web Application。

于是，許多問題的排錯就可以有大致的方向了。許多做ASP.NET的朋友都會問：“為什么我創建的ASP.NET AJAX項目可以運行”，但是用“ASP.NET Web Application”創建的項目就沒法使用ASP.NET AJAX了呢？很明顯，這個問題的關鍵不在“使用什么模板創建的項目”，而是這個項目中的內容是否可以執行，更確切地說，是某個文件夾下的內容能否使用 ASP.NET AJAX——因為對于IIS來說，它不會關心“項目”（也就是csproj文件）在管理哪些資源，它只知道“網站目錄”。

好，既然知道是網站內容的問題，那么接下來就應該比較的是“一個可以運行的網站”和“一個不能運行的網站”究竟有什么區別。ASP.NET站點最關鍵的東西便在于web.config，“能夠運行”往往也是web.config來決定的。例如，你有沒有正確配置HttpModule或HttpHandler。在許多情況下，解決了ASP.NET站點的web.config，問題也就解決了大半。同樣的情況還會有，為什么同樣的代碼（標記）在有的aspx上就能解析成功，有的就不行？那可能是web.config中沒有引入正確的control標記或命名空間造成的。

有朋友可能會說，你知道 web.config的那么多節點是做什么的，自然容易排錯，我都不知道，怎么知道問題在哪里？其實，我也不知道很多東西，但是我會比較。我一開始用VS 寫F#程序的時候，都只是用一個文件來練習。后來想要用多個模塊了，于是就創建新的源文件。但是我發現，main方法總是說寫在新文件里的模塊“還沒有定義”，這讓我很困惑。于是乎，我去網上找一些示例——不是普通代碼片斷，而是一些用VS編輯的小型項目，它們自然是能夠編譯通過的。例如，我拿到了項目 A，我就開始比較它和我的寫法究竟有什么問題——觀察下來沒有任何收獲，我還是覺得我的做法沒有任何問題。于是我嘗試著在A項目中添加我的模塊——奇怪，在A的main方法中還是訪問不到新模塊——這不是欺負人么！

于是我進行更深入的比較，比較除了源文件之外，它的項目設置和我的項目設置有什么區別——還是沒有！我抱著最后一絲希望，將A項目中的代碼添加到我的項目中來，編譯，還是失敗！但是看到這個結果，我反而看到了解決問題的曙光。因為我都已經把源代碼統一了，這樣可能發生錯誤的地方可謂少之又少。剛才我提到，VS將編譯工作交給外部命令執行，對于F#也一樣。于是我就比較項目A和我的項目在編譯時的輸出，終于發現兩者的區別在于調用fsc.exe的時候，參數順序不同。F#的編譯器和C#編譯器不同的地方在于，它對源文件指定的順序是有要求的，只有放在后面文件中的代碼才能訪問到前面文件中定義的內容，反之則不行。這意味著，main方法必須作為最后一個源文件存在。但是，VS并沒有提供一個選項來調整源文件的順序，既然這樣，那就手動編輯fsproj文件吧。至此，問題解決。

我被這個問題困擾很久的原因，就是在于我從來沒有去懷疑過F#編譯器對源文件的指定順序是有要求的。我之前也觀察過fsc.exe的參數，但是并沒有“看出”什么問題出來。但是，我會和一個成功的項目慢慢比較，把我的項目和它慢慢靠攏，我用這種方式排除了各種錯誤可能性，最終把我的關注點又“逼迫”到編譯器的參數上。進行比較，嘗試，最終解決問題。再此之前，我也不知道這一點，不是嗎？您其實也一樣，如果遇到了一個奇怪的問題，沒關系，找一個成功的案例，詳細比較為什么它能行而我不行，慢慢地向它靠攏。最終解決問題的時候，就是你獲得新知識的時候。這樣，你的“經驗”增加了。

類似的做法還有：不時有朋友會問到，它的 WebForm項目出現了這樣那樣的問題，例如在PostBack之后事件沒有執行，狀態沒有恢復，讀不到某個值等等。從我的經驗上來說，這是遇到了生命周期的問題。但是，生命周期是個復雜的玩意兒，除非我親手進行嘗試，我也不可能知道某個特定項目特定問題的解決方案。其實對于這種問題，最好的方法之一，便是從最簡化的模型開始嘗試。例如，您可以準備一個空白頁面，添加一些控件和代碼，執行，成功。然后，您將這個簡單的頁面向您的項目進行靠攏，一次增加一小部分，然后執行看看是否成功。直到某段代碼添加之后發現失敗了，您就知道到底是什么原因引起的。可能是新的代碼有問題，也可能是新代碼讓之前代碼的問題暴露出來了。

對于排錯來說，最關鍵的是思考和分析，而不是動手。我有時候見到一些同事在遇到錯誤之后就開始盲目地修改代碼，重試，最后就算把問題碰對了，時間也浪費了——而且還可能把原有正確的地方改壞了。要進行思考和分析，就要細心觀察，例如您有沒有看清異常的信息是什么？有沒有順著InnerException一級一級往下看，看看最終是哪行代碼出的問題？如今的框架，一般都會把錯誤信息寫的非常完整。記得之前做WCF的時候，它甚至會告訴你可以嘗試著修改配置中的哪個節點！如果您直接忽視這些，就喪失了第一手信息了。

還有，別怕英文，就個錯誤信息而已，沒幾個詞的。

但是我可以這么說，許多朋友都缺少思考。因為從他們給我的郵件上來看，根本沒有把問題描述清楚。我相信“如果說不清楚，那說明沒想清楚”。事實上，如果能把問題描述清楚了，一般也可以找出用什么關鍵字去搜索引擎上查找信息。我很奇怪，許多朋友還不會用搜索引擎，例如他們會對搜索引擎說很長一句話，而不是提取出中間的“關鍵字”進行查詢。更嚴重的問題是“造詞”。例如“注入”，這個詞很流行啊，腳本注入，SQL注入。于是很多人在提問的時候也一直“注入”，但事實上他的問題和任何一種“現存的注入”的含義都不同。當然，您覺得這是“注入”也沒有關系，但是至少描述一下在您的場景下“注入”是什么意思，對不對？而且，如果你用“注入”去搜索引擎上查詢，就會發現基本上找不到你想要的東西，因為“注入”這個詞在互聯網上有別的含義，它和你的含義完全不同，又能給你什么信息呢？

此外，查到內容之后，也要進行基本的信息篩選。例如，一些小站，垃圾站的信息就不要關心了吧。直接找一些著名的大站，如官方社區，文檔，博客就行了。

最后一點是為我個人而說的。如果您希望讓我分析代碼，還請把所有可運行的東西打一個包給我，并告訴一個略為詳細的步驟，讓我可以直接雙擊打開編譯執行并重現問題。如果您只給我一個代碼片斷，還無法編譯通過，或者還需要我自己去補充各類庫，那我就只能說聲抱歉了。同樣，如果涉及到數據庫，那么請給一個用于創建腳本和測試數據的SQL文件。此外，如果項目太大，最好也新建一個項目，只放一些核心的東西即可，關鍵在于重現問題。而且就我個人經驗來說，經過“提煉” 之后，說不定您自己就已經發現問題所在了。

原文鏈接：http://www.cnblogs.com/JeffreyZhao/archive/2009/10/14/about-debugging.html