今天先放圖哈。智能完成已經開始做試驗了不過距離能看還差很遠，所以今天先繼續談一下著色的事情。

    這就是我暫時實現的所有功能了。首先著色算法可以外掛，其次左邊那個邊欄（大小和繪制均可以訂制）操作他的時候會發生什么事情也是外掛的。著色器與“斷點變紅”是分離在兩個不同的插件接口里面的，原因上一篇文章說過了。你們可能還會注意到那個灰色的框框。那個框框的確是會被編輯器當成一個整體來對待，不過我絕對還沒有實現折疊。因為在我的設計里面，如何進行折疊應該是插件的事情，控件本身只要處理好怎么編輯和顯示就行了。還有一個比較難發現的就是，我這玩意兒也是支持輸入法的，輸入法的窗口會跟隨光標移動……

    在開發這個東西的時候我嘗試了兩種新方法。第一種是MVC。MVC開發高亮還真是容易啊，不僅文字緩存部分（C#也是可以精確控制內存的哈）可以獨立出來，連編輯操作（各種按鍵鼠標組合）其實也可以不做在控件里面。這樣有什么好處呢，當然是可以進行高強度的單元測試了哈。第二種就是GUI自動化，光對類進行單元測試還是不夠的，Visual Studio 2010為.net單元測試工程提供了一個Coded UI Test框架可以給我啟動一個獨立的外部程序（MFC寫的也行，WinForm寫的也行，WPF寫的也行，網頁都行）然后操作上面的各種控件最后拿到控件里面的信息。不過可惜的是我的文本框并沒有按照Windows的UI Automation標準來實現（從而讓盲人也能使用這個控件），因此只能進行鍵盤和鼠標的操作，至于我繪制的東西是什么則需要其他方法。C#跨進程怎么做最方便呢？當然是Windows Communication Foundation了哈。為了寫足夠的單元測試是要不惜一切D。不過顯然WCF的服務不可能做在控件里，因此我的solution下面暫時就有控件工程、測試工程和被測試的“獨立程序”工程了。

    有了GUI自動化測試，我在進行重構的時候，就可以放心的修改代碼，然后執行測試程序，去外面喝杯茶。過個幾分鐘測試工程就會跟我報告一共掛掉了多少個case，只要修好就行了。這種方法杜絕了絕大多數由粗心引起的bug。如果你在公司使用類似技術來對付你的代碼的話可以有效減少工作時間，從而讓公司可以榨取更多價值。

    操作的組合還是比較麻煩的。為了全套支持，我特地操作了一下Visual Studio 2010的文本框，然后對一些我看不順眼的行為經過修改之后，現在已經可以實現{LEFT, RIGHT, UP, DOWN, HOME, END, PAGEUP, PAGEDOWN, ENTER, BACKSPACE, DELETE}×{null, CONTROL, SHIFT, CONTROL+SHIFT}共44種操作方法。加上鼠標，突破半百。這么復雜的東西，如果沒有足夠的單元測試，也沒有足夠的GUI自動化測試的話，隨便改個什么都很有可能發生問題的。所以開發這類程序的時候要十分小心，一定要寫單元測試。

    至于著色應該怎么測試呢？只要有了WCF，就十分簡單了。測試程序發送兩個坐標，WCF服務返回坐標之間所有字符的顏色代號就行了。代號是可以在測試程序跟被測程序之間約定的，所以這種方法就讓測試變得十分簡單了。

    開發這一部分一共花掉我大約四天時間（假設不用上班每天能寫8個小時，累計出來的）。當然平時要上班所以實際花費是要多一倍不止的。其實當我在紙上畫出了上圖C#著色器的狀態機之后，也沒想到實現出來速度這么猛的。雖然著色器使用狀態機來實現已經是速度最快的方法了（經過大學4年寫編譯器的經驗……不過我后來用C++做出了一個能根據正則表達式在內存中產生詞法分析器的，比手寫的更快），不過還是要感嘆一下.net到了4.0還是比起當年的2.0要進步無窮多倍的哈。虛擬機可以在執行的時候才開始產生并優化x86代碼，可以讓程序越跑越快（非騙人，編譯原理小白請自行學習），這還是靜態編譯其所不能達到的。之前還看過channel9上面的視頻講微軟某個研究院在做一個全新的javascript引擎（看起來好像沒有加進IE9beta），就是用了動態的兩階段profile+optimize+codegen的方法，通過為瓶頸代碼使用激進優化方法，從而讓總體的運行和編譯時間的總和降到最低。生成X86什么的還是非常麻煩的，總之我已經被機器碼囧了半年，暫時不想碰JIT了……當然這是遲早要再碰一次的。

    寫到這里就先碎覺了，下一篇開始說之前在糾結的過程中產生的幾個智能完成的方案。遲早都要把它給做出來的。