這一篇其實並不會像前兩篇講太多有關工具設定或調整的內容，著重在一個重點「快」。很多人都會問我「要怎樣才能快速產出？」「要如何才能有效率的開發？」，要不然就是跟我直接說要我教他們如何快速寫程式。
其實這有很大的誤會，因為熟悉我的人都會知道我其實寫程式是很慢的，慢就算了，而且會非常吹毛求疵，因為我不希望我所寫的程式在交付上線之後會有嚴重的問題出現，所以我會很嚴謹地寫程式，尤其現在我已經在專案開發導入測試之後，我一定會在交付前將所有功能的測試給完成並通過後才會交出去，所以我寫程式會快嗎？當然不會有多快，但是我還是可以在同樣的時間內將功能給完成而且還包含測試，這並沒有什麼魔法或奇蹟，只是開發習慣的養成而已。
West Wind Web Surge (以下簡稱 WebSurge) 不只是用於 ASP.NET Web API 的壓力測試功能，也可以對 ASP.NET MVC, ASP.NET WebForm 或是其他網站應用服務進行簡單的壓力測試，而 Load Testing 也僅是 WebSurge 其中的一個功能，WebSurge 也有類似 Telerik Fiddler 的功能，可以針對指定的瀏覽器所發出的 Request 和接收的 Response 進行擷取，有興趣的朋友可以去 WebSurge 的官方網站裡進行瞭解。
不過這一篇文章只針對 Load Testing 這個功能作簡單的說明。
我在開發專案的時候一定會用到很多的介面，可以從我的一些系列文章裡可以看到，對於系統的抽象化是否能夠瞭解、掌握與充分使用，對於大型、複雜系統的分解與後續的測試都會有相當大的幫助，如果你對於系統抽象化的分析與解構都能夠相當上手，很多看似複雜、難以處理的問題都可以迎刃而解。
話雖這麼說，還是很多人對於物件導向的抽象化還是相當模糊，更別說將抽象化的概念去轉化到實際的專案開發裡頭，所以一個很直接的點就可以看出系統的結構是否良好以及後續的維護，甚至於是否具有可測試性都可以看出，就是看專案裡頭有沒有使用到「介面 Interface」，我知道這一段說法相當武斷與偏頗，不過就我目前所接觸到的情況都能夠看出端倪與跡象。
很多人對於介面，因為不瞭解以及不知道如何應用在實務上，所以就乾脆選擇不用。而另外一種狀況則是當專案使用了介面之後，在進入偵測模式或是在 Design-Time 時，當想要去看某個繼承於介面的方法時，按下 F12 後就會直接移到介面的定義裡，而不是繼承實作類別裡，然後為了要找真正的實作方法就要找很久 …… 不要認為有人因為這個理由就不使用介面，我還真的有碰到一個團隊因為這樣而禁止在專案開發時使用介面，夠瞎吧，我只能說世界之大、無奇不有，其實這肇因於對於 Visual Studio 的不熟悉以及個人觀念的不好而犧牲了讓系統邁向良好架構的機會。