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

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

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

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

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

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

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

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