安德魯的部落格

原來 .NET 早就內建 XmlNodeWriter 了...

最近事情一堆，上班忙上班的事，下班還在忙著研究 Enterprise Library, Entity Framework, 還有一堆五四三的，文章寫的就少了... 先跟有訂閱我 BLOG 的朋友們說聲道歉...。不過在寫新專案的過程中，意外的發現這東西，一定要提一下...

不知道有多少人用過 XmlNodeWriter ? 我用這東西用很久了，當年 Microsoft 推出 .NET Framework 時，強調有很強的 XML 處理能力，其中 XmlReader / XmlWriter 就是以效能為考量，讓你避開處理大型 XML 資料效能很糟糕的 XmlDocument, 也不用去碰很難寫的 SAX 的替代方案...

無奈 Microsoft 內建的 XmlWriter 少的可憐，只能寫到檔案或是 TextWriter ... 看看權威的 MSDN 告訴我們有那些 XmlWriter 可以用?

老實說除了 XmlTextWriter 之外，另外兩個很少用的到。XmlWriter 在輸出 XML 時很好用 (如果你只作輸出的話)，複雜的 XML 輸出用 XmlWriter 比用 XmlDocument 簡單多了，不過最常碰到的情況是我還是想用 XmlDocument 來操作 XML，不過其中一部份的 NODE 想用 XmlWriter 來更新內容...

古早有位好心的 MVP 寫了 XmlNodeWriter, 就可以讓我這樣用:
XmlNodeWriter Sample Code:[copy code]
```
            XmlDocument xdoc = new XmlDocument();
            xdoc.LoadXml("<root><node1><data/><data/><data/></node1><node2/></root>");

            
            XmlNodeWriter xnw = new XmlNodeWriter(xdoc.DocumentElement, true);

            xnw.WriteStartElement("newNode");
            xnw.WriteAttributeString("newatt", "123");
            xnw.WriteCData("1234567890");
            xnw.WriteEndElement();
            xnw.Close();

            xdoc.Save(Console.Out);
```
```
   1:  XmlDocument xdoc = new XmlDocument();
```
```
   2:  xdoc.LoadXml("<root><node1><data/><data/><data/></node1><node2/></root>");
```
```
   3:  XmlNodeWriter xnw = new XmlNodeWriter(xdoc.DocumentElement, true);
```
```
   4:  xnw.WriteStartElement("newNode");
```
```
   5:  xnw.WriteAttributeString("newatt", "123");
```
```
   6:  xnw.WriteCData("1234567890");
```
```
   7:  xnw.WriteEndElement();
```
```
   8:  xnw.Close();
```
```
   9:  xdoc.Save(Console.Out);
```
第一個參數是 XmlNode, 第二個參數是要不要清掉原來 Node 下的內容。很棒，我可以直接拿 XmlNode 當作 XmlWriter 輸出的對象，透過 Writer 寫出去的東西就直接反映在 XmlNode 身上了，省掉輸出成 Text 然後再 PARSING 回 XML NODE 這種蠢事...

前面只是緬懷 XmlNodeWriter 到底有多好用，現在找不到有多難過而已... 接下來才是正題...

不過現在想再去找 XmlNodeWriter 官方網站已經找不到了 @_@，原本這 lib 是 hosting 在 gotdotnet.com 這網站上，不過 Microsoft 已經把它關了，改成 codeplex.com / MSDN Code Gallery 取代，只好求助 GOOGLE 大神，無意間又發現這 Microsoft XmlTeam 的 BLOG，COMMENTS 有這麼一段:

# re: XML Features in the February CTP of Visual Studio “Orcas”
Friday, February 02, 2007 8:27 PM by Stuart Ballard

Is there going to be an XmlNodeWriter in Orcas? It's a fairly glaring hole, especially if you've ever wanted to apply an XSL transformation to an in-memory XmlDocument and get the result as another in-memory XmlDocument. You can pass the input to the transform via XmlNodeReader, but to get it back out again you just have to feed your XmlWriter to a StringBuilder and then parse it...

Fortunately my use case wasn't performance-critical, but it's still ugly...

# re: XML Features in the February CTP of Visual Studio “Orcas”
Saturday, February 03, 2007 3:22 AM by Oleg Tkachenko

Stuart, XmlNodeWriter in .NET 2.0 is hiding in

xmlNode.createNavigator().AppendChild() method. It can be used to populate XmlNode via XmlWriter API and so you can
XmlDocument doc = new XmlDocument();
using (XmlWriter writer = doc.CreateNavigator().AppendChild()) {
xslt.Transform(input, (XsltArgumentList)null, writer);
}
Mike, am I right that Orcas January CTP includes none of these coolness?

真是太機車了，這麼好用的東西藏在這種地方? @_@，枉我從 .NET 1.0 beta 就開始用 C# 處理 XML，連 XSLT Extension 都寫過一堆， Trace Code 也追到 XSLT 內抓過一堆問題... 竟然連這東西都沒發現? 可惡...

於是手又癢了，拿來試用看看，發現只要動手寫幾行 Code, 我就能把 XmlNodeWriter 變回來了，像這樣:
我的 XmlNodeWriter 實作[copy code]
```
    public class XmlNodeWriter : XmlWriter
    {
        private XmlWriter _inner_writer = null;
        public XmlNodeWriter(XmlNode node, bool clean)
        {
            if (clean == true)
            {
                node.RemoveAll();
            }

            this._inner_writer = node.CreateNavigator().AppendChild();
        }


        #region 無聊的 "延長線" 程式碼...

        // 略! 共一百多行，補上廿幾個 abstract method / property, 把它接到 _inner_writer 上

        #endregion
    }
```
```
   1:  public class XmlNodeWriter : XmlWriter
```
```
   2:  {
```
```
   3:      private XmlWriter _inner_writer = null;
```
```
   4:      public XmlNodeWriter(XmlNode node, bool clean)
```
```
   5:      {
```
```
   6:          if (clean == true)
```
```
   7:          {
```
```
   8:              node.RemoveAll();
```
```
   9:          }
```
```
  10:          this._inner_writer = node.CreateNavigator().AppendChild();
```
```
  11:      }
```
```
  12:      #region 無聊的 "延長線" 程式碼...
```
```
  13:      // 略! 共一百多行，補上廿幾個 abstract method / property, 把它接到 _inner_writer 上
```
```
  14:      #endregion
```
```
  15:  }
```
這樣果真可以 WORK 了 :D 不過要真正變出一個新的 XmlNodeWriter 代價還不低，繼承 XmlWriter 的後果是有廿幾個 abstract method / property 得補上實作... 全都是很無聊的 code, 就是拿 _inner_writer 的直接套上去而已... 像這樣:
"延長線" 型的程式碼[copy code]
```
        public override void Close()
        {
            this._inner_writer.Close();
        }

        public override void Flush()
        {
            this._inner_writer.Flush();
        }

        public override string LookupPrefix(string ns)
        {
            return this._inner_writer.LookupPrefix(ns);
        }
```
```
   1:  public override void Close()
```
```
   2:  {
```
```
   3:      this._inner_writer.Close();
```
```
   4:  }
```
```
   5:  public override void Flush()
```
```
   6:  {
```
```
   7:      this._inner_writer.Flush();
```
```
   8:  }
```
```
   9:  public override string LookupPrefix(string ns)
```
```
  10:  {
```
```
  11:      return this._inner_writer.LookupPrefix(ns);
```
```
  12:  }
```
這堆 Code 我就不貼了，總之可以 WORK :D

不過對 CODE 有點潔癖的我，越看越不是味道，就動起 Factory 的腦筋了。繼續改造一下... 原本 .NET 2.0 內建的 XmlWriter 就已經提供 Factory 的用法了，像這樣:

XmlWriter my_writer = XmlWriter.Create( ... );

不過沒辦法不改 .NET FX 原始碼的情況下 "加掛" 我自己的 Create(...) 實作，原本腦筋是動到 C# 3.0 開始支援的 Extension Method, 不過它只支援 instance method, 不支援 static method ... 只好改成這樣:
XmlWriterFactory 實作[copy code]
```
    public abstract class XmlWriterFactory : XmlWriter
    {
        public static XmlWriter Create(XmlNode node)
        {
            return Create(node, false, null);
        }

        public static XmlWriter Create(XmlNode node, bool clearnContent)
        {
            return Create(node, clearnContent, null);
        }

        public static XmlWriter Create(XmlNode node, bool cleanContent, XmlWriterSettings settings)
        {
            if (node == null) throw new ArgumentNullException("node");

            if (cleanContent == true)
            {
                node.RemoveAll();
            }

            XmlWriter xw = node.CreateNavigator().AppendChild();

            if (settings != null)
            {
                xw = XmlWriter.Create(xw, settings);
            }

            return xw;
        }
    }
```
```
   1:  public abstract class XmlWriterFactory : XmlWriter
```
```
   2:  {
```
```
   3:      public static XmlWriter Create(XmlNode node)
```
```
   4:      {
```
```
   5:          return Create(node, false, null);
```
```
   6:      }
```
```
   7:      public static XmlWriter Create(XmlNode node, bool clearnContent)
```
```
   8:      {
```
```
   9:          return Create(node, clearnContent, null);
```
```
  10:      }
```
```
  11:      public static XmlWriter Create(XmlNode node, bool cleanContent, XmlWriterSettings settings)
```
```
  12:      {
```
```
  13:          if (node == null) throw new ArgumentNullException("node");
```
```
  14:          if (cleanContent == true)
```
```
  15:          {
```
```
  16:              node.RemoveAll();
```
```
  17:          }
```
```
  18:          XmlWriter xw = node.CreateNavigator().AppendChild();
```
```
  19:          if (settings != null)
```
```
  20:          {
```
```
  21:              xw = XmlWriter.Create(xw, settings);
```
```
  22:          }
```
```
  23:          return xw;
```
```
  24:      }
```
```
  25:  }
```
沒事還繼承原本的 XmlWriter 只有一個目的，就是要延用它原來的 10 種 Create method 啊... 貼張圖為証，繼承之後我就有 13 種不同的 Create method 可以用... 不用再兩頭跑 (只是不能加在原本的 XmlWriter 上真是殘念， C# 什麼時後會支援 static method extension ?):

當然，原程式只要改掉如何拿到 XmlWriter 那行而已，其它都照舊就可以執行了 :D

有需要的就拿去用吧，CODE 才十幾行，還包成 DLL 實在太麻煩了，需要的直接貼到你自己的 CODE 裡就好! 要散怖都隨便，沒有什麼授權問題，唯一的要求就是讓我知道我的 CODE 你有在用就好 :D，想讚助我的也很簡單，BLOG 上該多點幾下的東西，沒事就點一點... 哈哈

2008/12/07 .NET C# Tips 作品集技術隨筆物件導向
Policy Injection Application Block 小發現...

因為工作的關係，最近正在研究 Enterprise Library 裡整合的 Patterns & Practices 介紹的各式 Application Block... 撇開其它的發現，有個東西一定要提一下，就是 Policy Injection ...

介紹文章我就不多說了，一樣網路一大堆，有興趣的可以看 MSDN 官方的說明。比較特別的是它的用法。當年剛開始研究 .NET 內建的 Role Based Security Control，才在讚嘆它的 code 寫起來真漂亮，只要加個 attribute, 就可以在 runtime 自動檢查呼叫時的身份是否滿足 attribute 的宣告，如下:
CAS範例程式: [copy code]
```
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]public void Foo() {    // ... }
```
```
   1:  [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
```
```
   2:  public void Foo() {
```
```
   3:      // ... 
```
```
   4:  }
```
不管你的 code 在那裡，只要呼叫這個 Foo method, 當時的身份 ( principal ) 如果不屬於 "Supervisor" 這個角色的話，就會引發 Security Exception... 當初看到這真是太棒了，我可以用宣告的方式來作安全控制，不需要在主程式裡加一堆囉哩叭唆的 code 來查權限...

不過當我開始研究如何 "自定" 這個行為，除了加上自己的安全機制之外，想更進一步的加上 Log 或是其它的檢查... 我才發現跟本辦不到。因為... 這行為是直接在 CLR 裡支援的啊，我可以加上一堆自定的 Attribute 掛上去，但是呼叫時完全不會觸發我的 code ...

之後研究過 AOP，發現 AOP 正是解決我這類問題的 Solution, 無奈那些 solution 都不大實際，就沒深入研究了。之後找到篇 MSDN 的文章，裡面提到 .NET Remoting 時，遠方會產生 Proxy, 同時 Client / Server 之間的溝通會介著中間傳輸層傳遞 IMessage 介面封裝的 message, 到另一端才會由 Proxy 解讀，然後用 Reflection 還原呼叫的動作... 利用 Proxy 在還原呼叫動作時，你就有機會插入你要的邏輯 (IMessageSink)，做到跟上面例子類似的功能。

還是很不實際啊啊啊啊，我沒事也不會去用 .NET Remoting 啊，用不到的話這招對我也沒啥用 (大錯特錯!! 當年的我真是太過自信了 :~~~~) ... 這事就一直擱著了，直到...

最近在研究 Policy Injection Application Block 時，讓我看到了似曾相識的 code:
Policy Injection Sample Code #1[copy code]
```
[AuthorizationCallHandler("operation-name")]public void Deposit(decimal depositAmount){  balance += depositAmount;}
```
```
   1:  [AuthorizationCallHandler("operation-name")]
```
```
   2:  public void Deposit(decimal depositAmount)
```
```
   3:  {
```
```
   4:    balance += depositAmount;
```
```
   5:  }
```
這段 CODE 跟前面 CAS 的範例作用差不多，一樣是在 method 被呼叫前作一次權限的檢查。不同的是 AuthorizationCallHandlerAttribute 是自定的 (由 Security Application Block 提供的)，它的作用比 ROLE 更進一階，是直接檢查授權的。之間的差別就如同 windows 大家都知道把 USER 加入 Administrators 角色的話，"預設" 就可以做大部份的事，但是你要在某個有 ACL 的物件 (如 NTFS 的檔案) 拒絕 Administrators 的存取也是可行的。前面 CAS 的例子就只是判定你是不是某角色的人，而這例子則是判定某個授權的定義允不允許你執行。

扯遠了，重點不在安全，重點是自定的 Code / Attribute 也可以這樣用啊! 由於我多年心裡的疑惑，挖出這段作法比研究 Policy Injection 更積極一點 (老闆對不起...) 哈哈，沒想到答案就在前文...

它ㄨ的!! 原來只是在 Local 使用 .NET Remoting ...

說穿了不值錢，你用的物件標上 Attribute 後，要透過它的建立方式 ( Create or Wrap ) 取得加料過的物件，再呼叫它就會有你預期的效果了。這加料過的物件，就是 System.Runtime.Remoting.Proxies.RealProxy 下的某類別啊啊啊啊... 意思是我拿這加料過的物件，就會透過 .NET Remoting 的方式去呼叫到我真正的物件，而 Policy Injection Application Block 正好就替我把我要作的動作給補上去...。

雖然心裡有被擺了一道的感覺，不過它的 code 包裝的真漂亮啊... 除了 Create 的方式由原本的 new .ctor( ) 改成它的 Create( ... ) 之外，其它就通通一樣了。更猛的是它還提供了幾個真的很實用的 CallHandler (就是呼叫時會加料的動作啦):
- Authorization Handler
- Caching Handler
- Exception Handling Handler
- Logging Handler
- Performance Counter Handler
- Validation Handler
- Custom Pipeline Handlers
大部份的 Handlers 都望文生義，像是 Logging 就是呼叫時替你加一段 LOG，而 Performance Counter 則是呼叫時就替你戳一下 windows 內建的 performance counter, 讓你可以透過 performance monitor 看相關統計 (如你的 method 被呼叫過幾次... )，更神奇的是 Caching, 如果你的 method 跑的很慢，加上去之後甚至是 cache 裡已經有了上次的結果，這次呼叫就直接 return 了... (你還記得你寫過多少次資料不在 cache 內就 insert 進去的 code 嗎?) @_@

如果你看這篇期望看到啥 Enterprise Library / Policy Injection Application Block 的深入介紹的話，很抱歉... 我還沒那本事，哈哈... 再過陣子研究出心得，可能會寫幾篇吧...。這類文章如果你不介意看英文的，官方的說明還有 QuickStart 的範例就夠你看了，可以參考看看，我就不獻醜了...。這篇純粹是為了這 AB 解除了我多年來的遺憾，特地留下篇記念用的... :D

2008/11/18 .NET C# MSDN Tips 技術隨筆有的沒的物件導向
重生的 IBM ThinkPad X40 ...

我自己用了快六年的 ThinkPad x31 掛掉了，又沒潑到水，送去 LENOVO 修理，就回我 "液體入侵" ... 換主機板要 NTD 26500 ... 錢太多才會修，因此就跟我姊ㄠ了她已經沒在用的 ThinkPad x40 來用用...

X40 什麼都好，就是敗在它那顆 Hitachi 1.8" HDD 效能實在太爛... 拿到 X40 後就馬上重灌 XP，剛灌好後就用 HDTune 測一下這顆硬碟的鳥效能..

後來也很巧，經過一夜灌了堆必要的軟體跟工具之後，突然喀啦一聲，硬碟就再也不能用了 :~ 上網找找有無硬碟可以買? 還真慘... 都是拆機或是二手，個人保固七天或是一個月的那種。Hitachi也停產了，除了容量有 60GB 的之外也沒別的選擇了。效能很鳥的硬碟，相對的 $$ 也不算便宜，害我考慮了半天...

後來決定用 CF -> IDE 的轉卡，加上忍痛買了張 SanDisk Extreme IV 8GB CF 卡，也就是俗稱 "偽SSD" 的解決方案，裝好後好像完全換了台電腦似的，剛裝好的 XP PRO (原版光碟安裝的，沒有刪掉一堆內建的軟體跟服務)，開機的 WINDOWS 光棒，跑不到一輪就進 WINDOWS 了 @_@，真是傻眼，效能的增進遠超過我的預期...

雖然容量小了點，不過效能跟原本的 1.8" HDD 實在差太多了，不足的容量就再補張 16GB SD 卡撐著用。只要不裝啥大型檔案，一般的 OFFICE 文件還不成問題，用起來也還不錯! 原本慢到想扔掉的 X40 就這樣又活了過來 :D

最後補上 SanDisk Extreme IV 8GB 的效能測試圖:

2008/11/06 敗家有的沒的
[RUN! PC] 2008 十一月號

YA! 第四篇!! :D 還是一樣要先感謝一下編輯賞光，讓我有點空間寫些不一樣的東西。

基本的執行緒相關的程式設計跟函式庫，講的差不多了，其實這些也沒什麼好寫的。接下來打算寫一些應用的模式，來談談有那些方法，那些設計方式才能夠有效的發揮多執行緒的優點。看了 .NET Framework 4.0 / Visual Studio 2010 的 ROADMAP，有一大部份的重點擺在平行處理，INTEL年底也要發表四核 + HT 的 CPU ( WINDOWS 會認為有八個處理器 )，軟硬體都備齊了，剩下的就是程式設計師的巧思了。

其實之前貼過幾篇類似主題的文章，只是這次把它統合起來介紹一下。生產線模式，如果簡化後就是 [生產者消費者] 的模式，而把它徹底一點的應用，則是上回提到 [Stream Pipeline] ..

這篇也是第一次在雜誌上嘗試說明比較偏設計概念的文章，實作比較少，很怕不合讀者的口味... 應該不會貼了就沒續篇了吧? :P 有買雜誌的記得讀者回函填一下，哈哈，也算是點鼓勵。這次範例程式也是 Console application (我不會寫太炫的程式 :P )，需要的可以點 [這裡] 下載!

2008/11/04 RUN! PC 專欄文章 .NET RUN! PC 作品集多執行緒技術隨筆
該如何學好 "寫程式" #5. 善用 TRACE / ASSERT

哈哈，這篇拖的夠久了 :P

上篇扯太多，寫到一半寫不完就留到這篇了。寫出可靠的程式，這是軟體工程師的基本要求。上篇提到了 TRACE / ASSERT 的應用，來複習一下:

TRACE: 原本是 C 的除錯用巨集，目的是用適合的方式輸出除錯用的訊息，用來跟一般的訊息輸出有所區別。因為用的是不同的方式輸出，可以很容易的統一關掉。隨著工具的進步，輸出的方式也越來越適合除錯，比如輸出到開發工具的除錯視窗，或是輸出成記錄檔等等。

ASSERT: 也是除錯用巨集，它接受一個 bool 參數，輸入值為 TRUE 時一切正常，就像沒呼叫一樣，輸入 FALSE 則會中斷程式，或是輸出顯目的警告訊息。目的在於確保程式的每個步驟情況都如預料般的順利。

這兩個東西從 C 的巨集，衍生出各種語言及環境都有各自的版本。它的目的很簡單，就是 [Writing Solid Code] 裡提到的:

用同一套程式碼，同時維護兩個版本 (RELEASE / DEBUG)，讓錯誤自動跑出來。

雖然這本書提到了不少技巧，正確的應用 TRACE / ASSERT 是最基本的。但是那些細節並不是主要的重點。重點是你在寫 CODE 時有時時刻刻記得要盡量減少 BUG 嗎? 你有正確的擬出對策嗎? 來看看上回最後一段範例程式:

加上 ASSERT 的算分程式碼:
```
public static int ComputeQuestionScore(XmlElement quiz_question, XmlElement paper_question)
{
    int totalScore = 0;
    int itemCount = quiz_question.SelectNodes("item").Count;
    Trace.Assert(quiz_question != null);
    Trace.Assert(paper_question != null);
    Trace.Assert(paper_question.SelectNodes("item").Count == quiz_question.SelectNodes("item").Count);
    //
    //  如果都沒作答, 此題放棄
    //
    if (paper_question.SelectNodes("item[@checked='true']").Count == 0)
    {
        return 0;
    }
    //
    //  題目的配分
    //
    int quiz_score = int.Parse(quiz_question.GetAttribute("score"));
    //
    //  答對一個選項的分數
    //
    int item_score = quiz_score / itemCount;
    for (int itemPos = 0; itemPos &lt; itemCount; itemPos++)
    {
        XmlElement quiz_item = quiz_question.SelectNodes("item")[itemPos] as XmlElement;
        XmlElement paper_item = paper_question.SelectNodes("item")[itemPos] as XmlElement;
        //
        //  算成積
        //
        if (quiz_item.GetAttribute("correct") == paper_item.GetAttribute("checked"))
        {
            totalScore += item_score;
        }
        else
        {
            totalScore -= item_score;
        }
    }
    Trace.Assert(totalScore &gt;= (0 - quiz_score));
    Trace.Assert(totalScore &lt;= quiz_score);
    return totalScore;
}
```
各位仔細看一下加上 ASSERT 的地方。大家寫程式，通常都是腦袋裡想著 “我要處理什麼問題” ，很少人會去想錯誤處理的部份。沒錯，這部份的確是吃力不討好，以此例來說，光是傳進來的參數就有可能狀況百出了。正常的流程都寫不完了，誰還有力氣去把這些錯誤都擋下來?

不過最容易出錯的地方也在這裡。我常在跟其它工程師說，正確的資料 (參數) 傳進來，本來就應該有正確的答案傳出去。難的是錯誤的資料傳進來，你還得回應 “正確” 的錯誤訊息回去，這才真的是個挑戰。這時 ASSERT 的效果就出來了。你可以把 ASSERT 想像成 “宣告” 的子句。以 line 5 ~ 7 行為例:

確保傳入參數是正確的:
```
Trace.Assert(quiz_question != null);
Trace.Assert(paper_question != null);
Trace.Assert(paper_question.SelectNodes("item").Count == quiz_question.SelectNodes("item").Count);
```
這三行看在我眼裡，意思就是:

這兩個參數不能是 NULL，而且兩個 XML ELEMENT 都要有一樣數量的子節點 (Element)，否則就不惜代價警告我

同樣的，在程式的中間，還有傳回值之前，也都可以用同樣的方式來替你的程式 “把關”。再來看看算完成績後，要把值傳回去之前的 CODE:

確保傳回值的範圍正確的程式碼:
```
Trace.Assert(totalScore >= (0 - quiz_score));
Trace.Assert(totalScore <= quiz_score);
return totalScore;
```
這兩行的意思就是:

不管成績怎麼算，每張答案卷最後的總分一定介於 0 ~ 滿分之間。一樣，有例外的話就不惜代價警告我。

聽起來蠻狠的，不惜代價…，不過使用 ASSERT 的話就真的是這樣。通常碰到 ASSERT 後，程式不是進 DEBUGGER 就是直接關掉了。不過請大家注意一下，並不是到處加上 ASSERT 你的程式就沒問題了。要搞清楚加上它的目的是什麼。它要抓的是你程式的 BUG，不是執行期的錯誤 (比如 USER 輸入錯誤的值，或是必填的資料沒填等等)。執行期的錯誤，你還是得乖乖的寫程式，不能用 ASSERT 替代。

舉例來說，如果最後算出來的分數是負的，則會觸動 return 前的 ASSERT。有些有點經驗又有點兩光的 PROGRAMMER 可能會自己顯示一些錯誤訊息。但是這跟本不干 USER 的事啊! 會出現這種情況，錯的一定是 “程式” 本身，也就是你看到 ASSERT 警告後就該來改程式抓 BUG 了。加上 ASSERT 的目的就是在你的程式到處布下眼線，任何一個地方偵測到不對勁，馬上通知你來處理。

當你有心把程式寫好時，你才會覺的這樣作是必要的，而不是累贅。你眼線布的越多，BUG就越難藏在你的程式裡。相對的，如果傳進來的參數就不對了，那應該怎麼辦?

這時就要小心分清楚你要抓的是 BUG 還是做錯誤處理了。如果參數是 USER 直接輸入的，那收到 NULL 或是錯誤的值本來就有可能 (吃芝蔴那有不掉燒餅的…)，你需要的是老老實實寫好錯誤處理的流程。但是如果你的 API 早已嚴格定義不接受 NULL，卻還是有白目的工程師硬把 NULL 傳給你的 API，那這時就是 BUG 了，應該用 ASSERT 抓出來，然後找到冤大頭叫他改程式。

不過這樣的 CODE 可不能交到 USER 手上。想像一下如果你正在用 WORD 打文件，結果碰到一個小 BUG，ASSERT 就跳出警告訊息要中止程式，你連存檔都來不及，大概會抓狂吧。這時就是一份程式碼兩種版本的作法發威的地方了。交給 USER 的程式，就應該是切到 RELEASE MODE (或是關掉 ASSERT / TRACE) 編譯的版本。這時所有的 TRACE / ASSERT 好像完全消失一樣，程式就如同一般情況運作。

當 USER 回報一些很難抓到的 BUG 時，這時就可以打開 ASSERT 或是改用 DEBUG BUILD 的版本，再讓 USER 去重現 BUG，這時如果你都有老老實實加上 ASSERT 的話，BINGO，問題在那就一目了然。看看是那一道 ASSERT 指令被觸發，就知道是什麼問題了。抓 BUG 最麻煩的就是找出錯在那裡，而善用 ASSERT 就可以讓 BUG 自己跳出來告訴你出了什麼問題，只要你養成好習慣。

再舉一個應用例。看到 Steve Maguire 先生舉這個例子，真是想拍手叫好。他舉了他們在開發 EXCEL 時的例子。EXCEL就是要替試算表作一堆運算，當年還在 DOS 時代，CPU怎樣都不夠快，RAM怎樣都不夠多，程式設計師無不絞盡腦汁，要榨出所有的運算能力，最佳化做到無所不用其極的地步。不過這種東西是錯不得的啊，少算了一塊錢還得了? 碰到這種問題你該怎麼辦?

通常，我們都會先有個安全的版本，算的不快，但是因為邏輯簡單，比較不容易出錯。這種版本寫出來後才開始想盡辦法，去改善程式讓速度加快。馬先生 (ㄜ… 是馬奎爾先生… ) 就充份應用了 ASSERT，隨時都要把 BUG 逼出來的精神，真的把 “驗算” 的方法應用上來。它的作法很簡單，同一張試算表，用兩份不同的程式碼各計算一次，最後再來比對一下結果 (驗算)。只要兩者得到的答案不一樣，那就是出問題了! 當然也有可能是安全的版本寫錯了，不過你至少多了個機會抓到問題，因為不一樣的話，一定 “至少” 有一邊是錯的!

沒有這樣的前題的話，各位看到可能都會在心裡想:

有沒有搞錯，程式都寫不完了，還要寫兩種演算法來驗算?? 老闆又不會多給我一點薪水…

沒錯，這的確是成本較高的方法，每套系統應該都有關鑑的地方，只要有絕對不能失誤的地方，就值得用這種作法。速度的問題怎麼辦? 很簡單。你只要在 DEBUG MODE 才啟用這 “驗算” 的機制，測試人員輸入各種數值做黑箱測試，如果每次測試的過程中發現驗算錯誤，則 “黑箱” 測試就能幫助你抓到只有 “白箱” 測試才有可能抓到的 BUG !

我寫的這個範例程式 (算成績) 其實也準備了兩個版本。上一篇貼的是基本的作法，結果比較可靠。而為了效率我也寫了另一份程式碼，用的是位元運算，希望藉著位元運算，一次就把多選題的答案給算出來。開發的過程中就用了 ASSERT + 驗算的技巧，它不會加快我寫程式的速度，但是它可以加速我找到 BUG 跟解決 BUG 的時間!

有沒有覺的這跟單元測試其實很像? 沒錯。單元測試就是一樣的觀念演變出來的作法，所以你用的單元測試 FRAMEWORK 也延用一樣的 ASSERT 使用慣例。你會發現其實之間的觀念都是相通的，只不過單元測試更進一步的把它系統化了，由原本四處藏在程式碼中的 ASSERT，抽出來成為一個一個獨立的 TEST CASE，由原本被動的執行時期檢查，演變為主動執行所有測試的 UNIT TEST。我覺的 Kent 在 XP (extreme programming) 裡舉了一個例子來說明單元測試，比喻的很貼切，我覺的也一樣能拿來比喻 ASSERT:

車子裝了煞車，是要讓車子能開的更快!

聽起來好像很蠢? 煞車明明是讓車子停下來的… 其實不然。想像一下如果你的車子沒煞車，你敢開多快? 了不起就是撞到不會怎麼樣的速度，或是油門放開就停下來的程度而以。有了煞車讓你有信心，碰到危險時你隨時能把車子停下來，你才敢把車子開上高速公路…

很有道理的比喻，ASSERT 跟 UNIT TEST 大部份人都覺的是 “煞車”，是拖慢你速度用的，但是也因為有這些 “煞車”，你才能放心的衝更快。當你有充份運用 ASSERT 的話，你就能很放心的寫程式，沒有後顧之憂。其實類似的關念，Steve Maguire 的書還有提到很多，只不過它的範例都是用 C 寫的 (還不是 C++ …)，看起來會吃力一點。範例程式可能對現今大部份的人都用不到，但是裡面的觀念跟作法還是很有參考價值的，手上還有這本書的人不妨拿起來翻一翻。

講到這裡，花了兩篇才講完第一個部份，主要的重點就是用 TRACE / ASSERT 來說明，要讓你的程式夠穩定，第一個要改進的就是你寫程式的想法，觀念及態度。各位不妨以這兩篇的例子，自己回想看看，你做到那幾項:
1. 你寫程式有考慮到這些問題嗎?
2. 如果你寫程式有用這些方法，有多少你曾解過的棘手 BUG 會變的迎刃而解的?
3. 加上 ASSERT 之後，你是否對你程式更有信心了?
4. 你是否更認同單元測試的必要了?
想法跟觀念有了改變，才有可能開發出優良的軟體。你開始認同這樣的想法了嗎? 恭喜你，你已經跨出第一步了。不過光是 BUG FREE 還不足以成為優秀的軟體工程師，這只是必要條件之一而以。除了把程式寫的 “可靠” 之外，接下來的挑戰是如何把程式寫的 “漂亮” ? 下回要開始來探討如何構思你程式碼的結構。什麼樣的結構，什麼樣的方式去分析你的問題，才寫的出架構漂亮的程式? 別急，請期待續篇 :D

–

註: 範例程式很多 CODE 被我跳過去了，有興趣的人可以抓回去研究看看… 請點這裡下載。

2008/11/03 系列文章: 如何學好寫程式 .NET C# 作品集專欄技術隨筆有的沒的物件導向

Search

Facebook Pages

安德魯的部落格

Sponsor Ads

My Popular Repositories

WebServerClock

能透過 Http Response Header (Date) 偵測網站的時鐘, 顯示該網站目前的時間的小工具。通常在搶購演唱會門票，購物網站限時搶購，或是連續假期訂購車票時，都需要在開放購買的那一秒鐘按下按鈕，此時搭配這個工具就能精準地掌握 server 的時間。

15 4 2018-05-19

SDKDemo

示範 API 與 SDK 之間的版本相容性開發範例。示範的開發過程，採用 git flow 的方式來進行版本控制，也包含了透過單元測試，同時採用舊版的 client 測試新版的 server, 確保 API 升級時的相容性問題。

10 2 2018-06-22

IP2C.NET.Service

IP to country search service / sdk / auto update worker.

9 2 2018-06-13

MeetUp.ApiTokenDemo

介紹跨網站傳遞授權資訊時的安全問題，用100行以內的程式示範數位簽章如何解決這個問題。也示範了這樣的技巧能解決那些更複雜的授權問題。有文字版本可以閱讀，也提供介紹的錄影，以及相關的 PPT 跟 source code.

6 1 2017-07-26

CommunityOpenCampDemo

Microsoft 主辦的社群活動研討會: Community Open Camp，我主講的場次 windows container 範例及投影片內容

5 2 2018-04-27

« 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 »

架構師的修練

原來 .NET 早就內建 XmlNodeWriter 了...

Policy Injection Application Block 小發現...

重生的 IBM ThinkPad X40 ...

[RUN! PC] 2008 十一月號

該如何學好 "寫程式" #5. 善用 TRACE / ASSERT