小朱® 的技術隨手寫

你覺得是 Sex 還是 Gender? 我敢說一定有很高比例的人覺得是 Sex，因為我以前也是這樣，但是到底要用什麼方式來命名，其實還是有些爭議。

Design Patterns 或 MVC 都是用來解決架構與設計上的相關問題，它給你的是方向，但真正實作出來的，其實並不是一定要 "依樣畫葫蘆"，只要在設計上有滿足 Design Patterns 或 MVC 的精神：職責分明，並且能解決你要解決的問題領域，就夠了。當你學習夠多的時候，自然而然就會有想法，而且自然會植基於 Patterns 之上來思考。Design Patterns 或 MVC 其實只是教你該如何去思考，是概念上的作法，但實作要靠自己實踐，打出一套能夠滿足 Design Patterns 的精神，並能完成問題解決的拳法，才是王道。

寫程式寫這麼多年了，雖然都是在微軟的平台上奮戰，但使用的技術也不少了，從早期的 VB4, ASP, VB6, Visual C++, .NET Framework 1.x, VB.NET, C#, ADO, ADO.NET, 一直到現在的 ORM, Entity Framework, async/await, ASP.NET MVC, Dependency Injection, AOP, Design Pattern, … 時代一直在進步，技術的演進會持續的上演，這不就是資訊業界 (尤其是軟體開發) 經常會遇到的情況嗎？所以一般來說也見怪不怪...

如果有訂閱 MSDN (或是你是微軟 MVP 又有訂閱 MSDN Utlimate Subscription) 而且又有在使用 Windows Azure Member Offer for MSDN Subscription 的人請注意，微軟將在 2013/8/1 起變更 MSDN 訂閱戶的權益，將原本固定額度資源的方式改變為以配發免費額度的方式，亦即原本是以資源與使用額度 (Resource-based) 的優惠限制，改為給予抵用金 (Credit-based) 的方式，這樣的作法對微軟來說可以更有效的控制與分配資源，但對我們這些已經在 Windows Azure 平台上做實驗以及使用資源的人來說就未必是件好消息了。

這幾年來，Web 的應用開發方式的發展有了不少的改變，JavaScript 再度成為 Web Application 的用戶端開發的顯學之一，伺服端也出現了一個叫做 node.js 的伺服端開發技術，它們兩個都有一個共通的特性：事件驅動式 (event-driven)，早先在 Windows API 以及 Visual Basic 上常用的程式開發方式，再次於 Web Application 上流行，這也象徵著 Web Application 己經成為一個相當成熟的應用程式平台。

網路雖然是一個匿名的交流環境，但並不代表在網路上的行為就不會犯法，已經有太多太多的案例，證明在網路上的非法行為 (正義魔人的人身攻擊行為，在網路上放話侮辱特定對象等)，還是會受到法律制裁的。盜文，也是一個犯法的行為。

寫過 ASP.NET Web Form 的人應該都知道使用者控制項 (user control) 這個東西吧，它允許開發人員對 Web 的畫面設計可重覆使用的網頁區域，在多數的情況下，我們都是用靜態的使用者控制項，也就是在 Web Forms 上放一個自己的 user control (*.ascx)，它會幫我們將對應的 HTML 繪製出來...

一定會有人覺得奇怪，為什麼到今天還在講物件導向，因為筆者認為物件導向是心法，觀念對了，寫出來的程式才會有一定的水準，而這套心法有很多東西可以講，不過筆者只會講中鳥階段應該要學會或養成的良好習慣。

今天討論的還是在物件導向的範疇內，因為物件導向的寫法和傳統的有些不同，思維更是不同。

今天要談的是物件導向的幾個基本性質以及衍生出來的特性。

當到了中鳥階段，表示已經工作了至少一年以上，對程式開發的工作有了最起碼的經驗，當然大多數都是 Coding 比較多，但是從中鳥階段開始，要接觸的可能就不只是 Coding，其中一項就是和使用者談需求。

[碎碎念] 程式開發領域由菜鳥到老鳥的成長歷程 (15) - 菜鳥階段-測試很重要。

雖然會有人說這東西不是在學校就學過了嗎？只是，有些現代程式語言內都隱含了它的概念，但卻有很多人無法意會，只因為指標作業被系統本身做掉了。

專題，又稱「實務專題」，是大學生活所學的最後成果，同時也會反應做專題的人是不是真的有投入心力，它也有可能會成為未來進入職場的入場券之一，所以請認真的看待它。

證照制度本身其實沒有問題，各大廠針對自己的產品或技術進行規劃，為了要確認某個人是否有足夠的能力能讓原廠背書，故設計了不同的門檻給有興趣的人報考應試，達到門檻後授予由原廠背書的稱號，我們稱的 CCIE, MCITP, CTT+, PMP, … 這些都是，同時原廠還會公布這些門檻的資訊 (考試重點，對應產品或技術等)，讓有興趣的人參考，以準備並加強自己的能力。其實每張證照真正的重點，應該是在加強自己的能力的過程，一旦自己的實力已經得到提升的話，拿證照其實真的只是一個必然得到的結果。

最近有很多讀者來信詢問公有雲與私有雲的差別，在課堂上也有學問詢問這個問題，所以我就以這篇文章說明我的觀點。

其實寫程式和小時候學寫字很像，小時候父母總是要我們多寫字，因為字如果不用寫的話是記不住的 (英文字也不例外)，每個人自從開始閱讀及寫字以來，至少都累積了數百萬字的抄寫經驗了吧，所以除非沒有寫過或鮮少寫過的字不會以外，常用的 5000 多字應該都會寫。自己寫也有個好處，透過筆和紙可以輔助記憶，所以很多人都習慣在背書時用手抄的方式，多抄幾次就可以記起來了。不過，如果從一開始都沒有用筆寫過字的話，就算讀了很多書，也未必會寫字。

如果你常上討論區的話，一定多多少少看到像 [Java vs. .NET] 或是 [學 C# 還是 Java] 這種討論串，這種議題多半都會落到針鋒相對，因為程式語言和平台這件事，在某種程度來說很像是信仰之爭，尤其像是這種本質就是針峰相對的不同語言，最後總是會變成謾罵或意氣之爭，但如果初學者也沾染到這股偏見的味道的話，對往後的學習成長可能會有相當負面的影響。

寫程式，在資訊業的行話來說，是指 Programming，意思是將事物程式化，透過程式來達成我們需要或想要的功能，而寫程式的這個人，通常被稱為程式員 (Coder)，台灣多半稱它為程式設計師 (Programmer)。

不要讓所謂的 [不用寫任何一行程式] 把自己的發展性侷限了

記錄(logging)這件事在中大型應用系統中，是非常重要的一環，它可以重現資料變動的前後狀況，以及是誰去動了資料，如何動資料等等，除了作為財務部門稽核的基本資料外，也是一種保護自己的證據。

我想大家都不反對，在剛開始學習寫程式的時候，最依賴的兩樣的東西，就是書 (book) 和範例程式 (sample code)，範例程式在學習程式的道路上一定是不可或缺的重要工具，它帶給你觀念與方法，讓你可以用相同的模式來做到相同的功能，但範例程式碼最終的目的，只是教你特定的需求要怎麼達成而已，若不將它融會貫通的話，很容易就傷到自己。

前幾天我在幫我顧問公司的員工上課，剛好講題就是 Software Architecture，我在課堂上順便問了一個小問題：Framework 和 Architecture 有什麼不同？結果學員多數都答不出來，因為那間公司都把 Framework 叫做架構，但光是架構這個詞在很多技術用語上都會被套到，那麼，Framework 和 Architecture 到底哪裡不同？

一般在寫程式的時候，往往都是要先探詢寫這支程式的需求是什麼，如果有些工作是由流程 (process) 構成的，或者是這件工作可能會橫跨不同的模組（或資料庫），又或者是這個程式預期未來可能會有什麼樣的衍生功能時，就可以試著把這些程式中共同的部份加以抽出，獨立構成一個公用程式庫 (utility) 或是基礎類別 (base class)，而將這些部份抽出的流程即稱為抽象化 (abstraction)。

最近好像很多人都在問這個問題，MSDN Library 資料量是數百本書的規模，而且MSDN Library有如微軟技術的經典，成經典者，均難讀通，要從MSDN Library數百萬字中找出自己想要的東西，其實是需要一點技巧的。

介面導向設計(interface-oriented design) 在軟體架構設計中，是一個必修的技能，不過在整個軟體架構領域中，它只是個入門磚而已，沒有它，想要做好軟體架構是很困難的，原因只有一個：它是基礎。

這裡列出一份針對軟體開發人員所擬的一百個問題，這些問題都是屬於軟體工程基礎知識體系 (Software Engineering Body of Knowledge, SWEBOK) 的一部份，試試看，你能回答幾題呢？