來源：Jeffrey Zhao
時常有朋友發郵件給我，說遇到了一個什麼什麼奇怪的問題，不知道是怎麼回事，希望我幫忙看看。我基本上每天都會抽出或長或短的時間來回復這些郵件，不過也經常發現，其實許許多多的問題都完全是有能力自行解決的。在很多時候，我發現許多朋友還缺乏最基本的解決問題，分析問題的方式。其實我在平時工作中也會遇到各種各樣的問題，有時候甚至異常古怪，但是在仔細分析之下，往往都能解決。於是我現在打算談點解決問題的基本方式，希望可以幫到一些朋友。
如果您也有著方面的體會，也可以分享一下，即使是某個簡單案例也是很有幫助的。
要解決問題，首先是要定位問題，配合正確的推理方式，再仔細分析，“動手嘗試”很可能只是驗證推理是否正確的手段而已，其實大部分的情況都可以用思考來得出（或排除）。要定位問題，很重要的一點便是要把概念理清。很多朋友會輕視概念，認為那種“理論”有什麼重要的，最關鍵的是“動手”——但殊不知概念能讓您的“動手”少走很多彎路。
例如，在一個問題出現之後，我往往會心想，這到底是“開發時”還是“執行時”的問題。我們在做開發時會用到許多概念，有些是“開發時”的概念，有些則是“執行時”的概念。我們開發會用到很多工具，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檔案。此外，如果專案太大，最好也新建一個專案，只放一些核心的東西即可，關鍵在於重現問題。而且就我個人經驗來說，經過“提煉”之後，說不定您自己就已經發現問題所在了。
