小朱® 的技術隨手寫

這一份是我幫駐點的公司所設計的一份程式碼與資料結構的命名與設計規範，應觀眾要求，先把一些駐點公司的資料清除以後貼上來，不定時更新，如果對這個有特別想法的也可以提出來，可以隨時更新這個規範的內容。

其實是不只是學習寫程式應有的態度，也是平時面對許多生活大小事的基本態度。

抽象化 (abstraction) 能力在物件導向領域以及 Design Pattern 中是非常重要的一項專業能力，還可以衍生出一項重要的能力，即分層 (layer) 能力，這個能力可以進一步協助抽象化能力降低元件之間的耦合性，也可以協助將應用程式切割的更細，強化程式元件的內聚性，它亦是目前軟體工程鼓吹的領域知識設計 (domain design) 的基石。

也許開發工具或元件供應商把工具和元件設計的太簡單，讓很多新手開發人員在使用這些東西時，在不知不覺中產生了一種錯覺：我只要會使用這些東西就好，不用學它背後的東西，但這是錯誤的觀念，它不但會限縮你的發展空間，也會讓你在碰到問題時不知所措。

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

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

適當的設計，應該是考量各種可能情況，對程式做的具彈性且可重覆使用的軟體設計，除了基本的物件導向規範以外，還要加入一個守門員的角色：規則（Rule）以及驗證器（Validator）。

只要程式開發久了，又有面對過不同層次的專案（例如產業不同，性質不同，應用方向不同或是不同的領域知識等），通常都會接觸或是使用很多的技術，而且技術的學習力又和自己本身的基礎能力有相當大的關係，它會左右你學習新技術的快慢，不過今天要談的倒不是學習力，而是決策力（Decision Making）。

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

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

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

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

在類別中使用中介資料宣告，讓開發人員在使用你的類別時可簡單的以宣告方式即可設定元件資訊，而不需要寫程式。

「a... 怎麼看起來好像又回到了 ASP 時代？」
「a... 這個好複雜哦，看不懂捏...」
我想，這是初次看 ASP.NET MVC Framework 的第一印象吧，因為我第一次看到時也有這樣的疑問。

URL Rewriting，這個好像似曾相識，又覺得很陌生的技術，已經隨著資訊安全與 SEO (Search Engine Optimization) 的腳步，逐漸影響每個 Web Developer，不論你是走哪個技術的（ASP, ASP.NET, PHP, JSP, Ruby, Perl, ...），基本上都很難不去重視它，因為它其實可以幫你很多忙。光是一個 REST 的 URL 樣式，就可以讓很多人眼睛為之一亮。