~.:.': .NET碎碎念:'.':.~: Microsoft TechEd 2008 心得

繼前一天充實的課程之後，接下來我剩下兩堂課程要參加，
教室都是大會堂(最大間的，可以容納1208人)，
以下是我的心得：

0850 ~ 1000
課程主題：單元測試(Unit Testing)實務分享
講師：李智樺

李講師的講課內容很生動有趣，不過他的 blog 實在是無敵難找的，
連黑暗執行緒大大也找不到，希望投影片裡面有附連結。

(由於上面的連結就是黑暗執行緒大大的筆記內容，因此我就以那篇筆記為基礎，
另外作一些補充。)

採用Test Driven Development的開發模式，會強迫你進一步深入思考程式的各方面(架構、需求、作法)是否合理(所謂的 Second Thought)，這點非常重要，
在動手做之前寧可多花一些時間做深入的思考，
可以有效減少在程式中埋下難解的邏輯錯誤的可能性。

(關於如何利用 VS 進行 TDD 開發，可以參考 DNN CEO 的這篇 post)
再一次強調 Martin Fowler 這位大師所說的：「不要相信文件，只相信 code」，
但是通常 code 數量太多(成千上萬)，那麼要如何相信呢? 利用 Unit Test 來驗證!!

在工作一年後，深深的覺得這句話果然是至理名言，非常中肯；
而李講師所提倡的「以 Test Case 作為交接以及外包廠商的第一道驗證」的觀念
我也非常認同，不過這應該需要公司的 Top Management 下決心去貫徹，
否則很難全面落實。

李講師還提到「己所不欲，勿施於人」這句老話，也就是說 101% 的 developer 都曾接手過文件敘述含混不明，程式碼混亂不堪(就算很乾淨也可能因為數量太龐大而不易了解)的案子/元件，這絕對是很痛苦的事情，因此身為一個優秀的 developer就該要有一個 discipline：當離職前將自己手上的工作交接給接班人時，
應該就要附上 Unit Test 的程式碼，並且實際 RUN 一遍!! 如果連這個最基本的門檻都沒辦法達成，說真的，的確是很難檢驗這些程式碼到底有沒有問題。
(人工測試能做到多高的 Code Coverage? )

從這邊繼續延伸下去，由於接下來我也要開始著手開發新的元件，
所以最近有時間就會去 Survey 自動從 Source Code 產出文件的工具，
因為只有 Source Code 才是最準的!! (Source Code 就是你最好的老師，
一切的真相都在 Source Code 裡。) 等到有初步的結果我再整理 PO 上來。
綜合整理在 TDD 思維下的開發順序；

(1) Write Test Case (with dummy input/output)
(2) Write your code
(3) Modify the input/output ofthe Test Case
(4) Run Unit Test --> Target: 100% pass
(5) Run Code Coverage (Target: at least over 80%)
--> May need to write more Test Cases to improve code coverage
(6) Refactoring
(7) Iterate the above steps until the System is complete
整合測試和單元測試的差異：這應該還蠻好理解的，單元測試只管自己這個小小的 function 是否可利用 (正確的) input 產生 output，並正確處理例外狀況。
而整合測試則是要確保當綜合個別小小的功能時，能夠正確完成一個大的目標。
我也聽不懂劍潭的笑話 .... || 笑點也許是這個鄭成功把寶劍投入潭中鎮壓鬼怪的故事根本就是 100% 唬爛的 ... =.="
其他 VS 有多好用好用之類的就不用提了，我覺得李講師的台風真的很不賴，
但是 maybe 是受限於大會堂的性質，必須要盡量淺顯易懂，
因此其實內容講得有點重複(也許是故意重覆來加深大家的印象)，
接下來他會在 10/16 的MSDN 研討會講 WCF，如果有空應該去捧個場，
希望可以講得深入一些。

0850 ~ 1000
課程主題：提升ASP.NET網站延展性的策略與應用
講師：郭明祥

這一場說實在是很無聊的，跟上一場相比，講師的風格差太多，
這場的講師完全就是 100% 自己講自己的，完全不管台下的反應，
本來這個 session 規劃到 11:30 結束，結果我和我同事 11:50 就受不了走了，
他整個就還是依然故我的繼續講，甚至有兩個工作人員上台去提醒他也沒用，
又沒有講得特別吸引人，整個聽完就沒甚麼印象，
還耽誤到我們中午吃飯的時間 ...

Anyway, 延展性基本上分 Scale Up (向上延展，擴充本機的硬體)，還有 Scale Out (以多台機器提供服務，例如 Cluster / Web Farm 等架構)，其中有很多要考量的細節，
必須慎重評估各種方案以及整個 application 的特性和應用情境，才能做出最好的選擇。

因為細節沒印象了，大致上是這樣，花了很多時間講細節 (e.g. ASP.NET的運作)，
裡面的確是有很多學問，因此 developer 不能只關注軟體面(雖然光是軟體就很難精通)，
必須要一定程度的了解硬體上有哪些要注意的地方，以及有哪些可善加利用的特性，
如此才能打造出真正擴充性高的應用程式。

另外他有介紹 Fiddler 這個效能監測工具，除了監控封包併計算統計數據外，
還可以產出不錯的圖表，而且是免費的，算是蠻實用的。

這一場另一個有趣的地方是，我注意到有一位聽障的朋友坐在第一排，
然後旁邊有人即時手語翻譯!! 這實在是太酷炫了，我以為手語只能表達一般生活用語，但是顯然手語也是可以表達「Application Scalibility」、「ASP.NET Worker Process」等專有名詞的!! 因此在這裡要對那位即時手語翻譯大師敬上十二萬分的敬意!!
雖然不知道這是不是微軟提供的服務，不過希望我永遠都不需要用到 Orz..

現在由於太想睡所以實在想不起來他到底還講了啥，似乎還有一個計算 remponse time 的公式，不過剩下沒寫到的，就一起放到下一篇的補完裡面好了，預計還會加上 Rosario、Oslo、SDLC、Live Mesh 等等的資料，敬請期待 ~~~