在軟體開發過程中，寫出影響效能或者有bug的**，都是我們無法迴避的現實問題。
不過，如果能夠在程式發布前（自測或者測試階段）將這些問題找出來，我想大家都是可接受的。
今天就來介紹一種方法，用來發現在**開發過程中，容易被我們忽略的一些問題，而這些問題其實是容易被發現的。
將要介紹的方法需要使用fiddler這樣一款工具，我將演示如何使用fiddler來發現404錯誤，以及較大的響應輸出問題。
我認為這二個問題實在太低階了，所以我設計了這個方法，並寫了這篇部落格，希望大家能喜歡。
我發現，許多人對於這二類問題（404錯誤和較大的響應輸出）都很不在意，好像它們根本不會對乙個**有任何影響似的。
難道真是這樣嗎？
我認為：如果你做的**程式，使用者訪問量很小，或許的確可以忽略它們。
否則，我還是建議你應該糾正它們，下面我來解釋它們的危害。
404錯誤
我一直認為404不僅僅只是乙個數字，過多的404也會影響程式的效能。
通過對404錯誤的分析，我發現多數的404錯誤都與一些資源檔案的引用有關，比如**中引用了不存在css或者js檔案，這些404錯誤發生時，可能並不會影響頁面的正常顯示，因此，這類錯誤根本就不會引起一些開發人員的注意。
再加上，許多人又喜歡複製貼上，導致這類錯誤越來越多。
為什麼我會說【過多的404錯誤也會影響效能】呢？
因為當404錯誤產生時，iis其實並不只是返回這樣乙個數字，而是乙個完整的http響應，響應的內容是乙個正常的網頁。
不同的iis版本的這個404的錯誤頁面長度並不相同，iis6預設的404錯誤頁面長度超過2k，而iis7.5的預設錯誤頁面會超過8k 。
雖然這個響應看起來並不大，但是由於請求不成功，每當開啟這些頁面時，請求會重新發起，數量會越來越多。
反過來，我們可以想一下：如果要引用的資源檔案存在，這些檔案僅僅需要請求一次，瀏覽器就會快取它們，根本不需要每次都重新發起請求。
這樣一來，客戶端減少了請求數量，伺服器減輕了連線壓力，那些無意義的404響應所浪費的網路流量也能消失。
因此，過多的404請求簡直是乙個惡性迴圈，它延長了頁面的顯示時間（前端），給服務端帶來了連線壓力，也浪費了網路資源。
較大的響應輸出
較大的響應輸出，應該是容易理解的，那就是：服務端返回的結果太大了。
我們可以想像一下【較大的響應輸出】意味著什麼。
1、瀏覽器顯示乙個【很大的網頁】，是不是會比較慢？
2、【很大的網頁】是不是會花費較長的網路傳輸時間？
3、服務端生成【很大的網頁】，是不是也要花較長的生成時間？
4、如果這個【很大的網頁】的結果來自於資料庫的查詢結果，會不會給資料庫也帶來較大的壓力？
產生這種情況就典型的場景可能由於一條sql查詢引起的： select * from *** wherename=@name
或許在早期階段，***表的記錄很少，或許當初在設計時根本沒想到name會存在一大堆的複製資料時，再或者，當在本地環境測試時，網速根本不是問題，而瀏覽器的渲染速度的延遲又沒有被發覺時。
我們可以想像一下：這樣的程式如果部署在網際網路上執行，結果會如何？
關於【較大的響應輸出】，還有二個可能發生的場景：
1、往viewstate中放入乙個很大的物件。
2、展示乙個樹形結構，或者是乙個沒有where條件的查詢（都屬於不分頁情況）
當以上這三類情況發生時，你認為效能還能接受嗎？使用者還會滿意嗎？
用fiddler發現這些問題
前面我詳細說明了二類低階錯誤的危害，下面再來說說如何盡早地發現它們。
我想許多人都應該用過fiddler，它能夠方便地讓我們知道瀏覽器發起的每個請求的request/response，通常用於除錯程式。
在fiddler中，404錯誤的請求會用紅字醒目地顯示，每個請求的響應長度也會單獨地顯示出來，貌似直接用fiddler也能容易發現404錯誤以及較大的響應輸出問題。
然而，當訪問過多的頁面後，fiddler會顯示非常多的請求記錄，因此，那些低階問題會被淹沒，我們要想發現它們，可能需要花費一點時間。
針對這個問題，我為fiddler定義了二個規則：
只要開啟它們，前面所說的二類低階問題很容易就能發現：
注意：這裡只顯示符合規則的請求（存在低階問題的請求）。
該怎麼合理地使用這個方法呢？
1、如果你是開發人員，請在自測時，開啟fiddler，並選擇我定義那二個規則，
2、如果你是測試人員，請在測試時，開啟fiddler，並選擇我定義那二個規則，
3、然後，你們平時該做什麼就做什麼吧，。。。。。。
4、測試結束後，再看一下fiddler視窗，有沒有記錄顯示出來，如果有，那就是發現低階問題了。
所以，我認為這個方法不會給開發人員以及測試人員帶來過多的負擔，畢竟，這個方法不會給他（她）們測試時增加任何負擔，唯獨要求開啟一下fiddler，最後在測試完成後，再來看一眼，僅此而已。
或許有些人認為：分析伺服器的iis日誌，也能發現這二類問題。
是的，我知道分析iis日誌也能發現這些問題，但是，分析iis日誌，是不是晚了？
你想過沒有：這樣的問題是不是已經影響了使用者？
反之，不讓使用者【體驗】這些問題，是不是更好？
換句話說：你是否希望發布乙個有缺陷的程式？
如何自定義fiddler過濾規則
如果希望自定義fiddler規則，建議安裝：syntax-highlighting 這個fiddler外掛程式。
然後，開啟自定義規則視窗：
此時，會顯示fiddler的規則**，供你修改：
在這個視窗中，右邊顯示了能在自定義規則中使用的一些物件型別，以及它們的字段（綠字），屬性（藍字）與方法（黑字）。
我們可以在寫規則時參考這些資訊。
說明：此規則檔案儲存在：x:\my documents\fiddler2\scripts\customrules.js
還記得我前面的截圖中：我在fiddler的rules選單下面增加了二個自定義規則 嗎？
定義規則選單的**在前面的截圖中（找漢字就能發現，最後4行**）。
選單定義後，還需要在onbeforeresponse方法中新增一些處理**：
最後，我還要再說一句：
如果你不希望發布有缺陷的程式，並且不希望後期返工，那麼可以嘗試一下本文介紹的方法。
程式在發布前就應該發現的一些錯誤
目錄 404錯誤 較大的響應輸出 用fiddler發現這些問題 如何自定義fiddler過濾規則 在軟體開發過程中，寫出影響效能或者有bug的 都是我們無法迴避的現實問題。不過，如果能夠在程式發布前 自測或者測試階段 將這些問題找出來，我想大家都是可接受的。今天就來介紹一種方法，用來發現在 開發過程...
程式設計師應該閱讀的一些書籍
本系列文章由 yhl leo 在stackoverflow上有兩個有意思的問題調查 哪本書是對程式設計師最有影響且有必要閱讀的？和哪些非程式設計的書是程式設計師應該閱讀的？兩個調查問題都是7年前提出的，距今前者吸引了801053人訪問，後者也有60192人訪問，如果你是個程式設計師，一定有興趣看看這...
我在c 程式調式的一些筆記
1 char buff new char currenttask.receivesize 當buff的位置發生偏移時，在delete buff之前，要將buff的記憶體位址恢復到最初狀態 2 要善於使用除錯快捷鍵 vs2013 f5 調到一下個斷點 f11 進入方法內 f10 單步除錯 3 合理使用...