很早的時候， C++如此神聖。一次週末，我跑到yqd那裏，邊吃麪邊看他寫程序，Borland C++的，看到對話框閃爍下面掩映着代碼，有不少 ::Foo()之類的寫法。覺得很酷。這個：：是做什麼的?不過當時沒有好意思問,下來也沒有搞的很清晰。相對於C，Pascal那些翻來覆去的Function ,struct ，C++有 tons of features 值得探索，顯得如此的有吸引力。
當時公司買了一套Borland C++。光盤怎麼的到沒有引起我的注意，倒是兩箱子的Borland的配套手冊（20本吧）讓我神往，摸着進口的紙張，眼神散亂，光暈中，我覺得我就是一個高手。
可是，當時的項目我實在很難理解。爲了訪問數據庫，需要編寫一堆代碼；爲了創建一個UI，也要生成一堆代碼——還看不懂,比如progma ,BEGIN_MESSAGE_DECLARATION這樣高貴的代碼之類的——一個字符寫錯，就是一堆阿貓阿狗的錯誤。玩人啊。
然後狂看C++，繼續昏倒。那會的面向對象基本上都是以C++爲藍本的。僅僅是多態、繼承都讓人昏昏然。何況還有構造函數，析構函數，友元、模板這樣的概念。尤其是繼承，難道代碼不就是一堆機械的東西嗎？怎麼還可以像是生物一樣繼承呢？
C++太過複雜，太早標準化，實在是一個災難。比如Windows內最基本的消息處理的轉發，它必須用宏來完成，後來的OLE封裝，也大量的使用了宏，只是爲了符合標準。每當我看到有些類庫的齷齪設計而百思不解的時候，往往會想到：偶，因爲要符合標準啊。Shit, 去TMD的標準。
書看的比較多了，慢慢的我的感覺是，把C++的東西都搞明白，要一年；把MFC 類庫用的熟練要一年，還需要了解Windows的消息處理，句柄，回調函數這些非常基本的概念，再來一年。等學成的時候，人都餓死了。
接下來一個C++項目比較簡單，是一個數據導入程序，把數據導入到LotusNotes內。花費了兩週時間，處理若干種格式。我發現只是使用類，不管面向對象，UI也不多的情況下，也是比較容易的。至於代碼職責分離，何必管那麼多，所有的函數都放到一個類內就行，反正也不復雜。在這個項目中，我使用了CString類做字符串處理，完成後，我牛哄哄的覺得C++就是我親戚，然後我順便用Delphi做了同樣的工具，邏輯是一樣的，而只不過換用了Delphi的string而已。我發現效率上來說，“神聖”的C++居然不如Delphi。——光環消失了。我甚至覺得C++的存在根本就是欺騙。因爲有人喜歡複雜——這不可怕，可怕的是他喜歡複雜而又駕馭不了複雜。
後來用C++做了一個語言解釋器，發現這個C++的類庫用來做語言真的是方便，其實C++在這個方面非常強大，所有，我認爲CXX雖然是設計爲通用語言，但是很多細節的引入是爲了解決語言，編譯器，操作系統之類的特定需求，故而做應用軟件實在是不適合。並且異常處理，也是比較齷齪的。這些年的重要語言進步，如內置多線程，異常處理，消息處理，UI設計，重構等在C++語言本身體現不多。C++來自於80S，現在在大部分領域都顯得蒼老而過時。即便如此，那個年代，人們瘋狂的用C++替代老的編程語言，作爲C++的作者，我認爲他應該是憂心而不是快樂。很多的應用程序，弄Delphi反而更好。但是Delphi是幾個強人在搞，Java是一幫和我們想法接近的人在搞，而Dotnet把Java的都弄過來在加上一幫強人在搞，因此，儘管DotNet並沒有什麼東西拿出來一招把人打翻，但是用起來真的很貼心、樣樣都很如意，沒有什麼特別扭着乾的——無論語言設計還是類庫設計。被C++禍害的人們都無比喜歡C#，儘管它的本地化調用很醜。
這樣我的看法是，軟件的東西開始不能弄太多的概念，而必須從例子出發，從項目出發。打入一個鍥子，然後尋找下一步的方向。
在做Lotus項目中，我發現很多時候，我是在訪問Word。因爲Lotus作爲文檔管理系統，其實管理的內容就是Word。大量使用VBA和Word的類模型，體驗着業界老大微軟在API設計方面的巧妙和全面。我也夢想，某一天，我的軟件也可以想Word，LotusNotes,AutoCAD 那樣，有完整全面，考究的API ，給大量的程序員一個可以踩的肩膀。
2002年的時候，對UML非常着迷。 看了很久的書，也看了不少UML的圖，可是一直不知道怎麼樣。有點天討論問題，劃了兩個框，一個線，說這個是bill，那是是detail，兩者是1對多的關係，然後我突然明白了UML的用處：確定一件事情，然後分解爲幾個類，指定他們的關係，這就是最簡單的UML應用。隨後，我在很多項目中使用UML繪圖。直到發現了重構，我覺得重構是更好的學習和表達設計的方法。我甚至把UML邊緣化過，在n個項目中，我都把UML作爲一個不選的工具，而更多在重構的方法，通過對比代碼來發現更好的設計。當做新的打印管理器的時候，我發現，UML圖可以對這樣的一個耦合關係非常複雜的、非常典型的對象系統中發揮很好的big map的作用，並且讓我們討論的時候更加方便。
當做進銷存的時候，我發現雖然我知道設計中有那些類的存在，但是非常不爽的是：爲什麼代碼內就不能和設計一致，也用類的方式去實現？有一段時間，我非常反感DataSet，因爲它的存在，數據和UI就可以直接的關聯了。就是說，即便在數據和UI之間沒有Object Model，它們一樣可以協作的很好。很多時候，對象是不必要的。如果真的要做一個完整的 Object Model ,然後需要把Object映射到Data，在把Object 映射到UI也是可以的，但是沒有任何基本架構可以直接使用，尤其是在Delphi內。都要自己完成，估計效率也會比較成問題。我還真的嘗試過這樣做，但是從頭搭配一個體系，何其困難。玩了，也失敗了。我知道只要使用了DataAware的體系，OO就只能成爲整個系統中的點綴，但是還是選擇了DataAware體系！
2004年，我開始接觸重構，2005年，我第一次進行了一次完整的重構。針對一個短信項目。我把一個巨型的、職責混雜的類拆開爲若干個職責明確的小類。這次成功讓我非常愉快。隨後在2009年初，我們開始在fx項目中正式引入了重構技術。2010年底，這個項目組從asp開發過渡到C#開發，從面向過程開發，到OO開發，從僅僅完成業務，到開始討論面向對象，討論設計，討論職責分析和重構。然後CM、HH等也開始跟進。我認爲我看到了技術人員的提升、看到了大家對技術的熱愛，人就是IT企業的靈魂——這是我所樂見的。而重構可以更加安全的從A代碼到B代碼，對於我們這樣的老產品的公司，重構是很好的改善代碼質量、提升技術人員滿意度的好方法。
有時候，人的特長真的是命中註定。比如我以前對非常具體的應用編碼之類的一直興趣不大。而直到發現重構，我才覺得這是我最喜歡做的事情。因爲我一直反感複雜的做法，垃圾的代碼，職責不清的設計。而重構是解決這些問題的法寶。很久以前，我剛剛從業的時候，還根據我們的代碼逐步的提煉了一些小的技巧，比如查表法、遞歸法等，但是直到看到《重構》，才真的把它當成一件獨立的工作，開始系統化我的思考。我對重構如癡如醉，反覆的閱讀MF（Martin Fowler）的《重構》，看了中文版，再看英文版，在看中文版...。然後看Kent back 的書，Agile等衆人的書，熊節和鄭華的博客，MF的Bliki，自己寫重構方面的博客，爲各個項目組、外部的俱樂部提供講座和諮詢，提煉重構的各種數量化指標，甚至直接編寫代碼並形成套路，etc。
直到最近的fx項目，我依然會思考這個問題，爲什麼具體的商品，職員等實體都是客觀存在的，但是代碼中就是不能很好的用這樣的類來表達？實際情況是，我們做了很多的類，但是Runner有一堆，很多QueryParams和Class 的轉換，Hash之間和互相轉換，大量的字符串比如CommissionWJGB之類的；對應的實體類比如Ptype即便有，也是隻有數據，沒有方法。我想最終的目標是比較清晰的，但是從老的代碼一點點的遷移多來，確實需要一個過程。並且考慮到現在平臺的代碼異步運行的要求，三層分佈代碼的要求等特殊的情況。所以，在OO的探索方面，我們依然在路上。我們依然在完美的路上，也許再過兩年，fx有更多的實體類，更少的事件類和Runner類，UI和Model分離的更加清晰，代碼更加直觀而不混淆，即使OO的初學者也不會感到追蹤代碼困難，OO難以掌握，那麼我們就成功了。這不但是重構和OO的成功，而尤其是個人的提升，進而導致公司技術的成功。
個人的技術提升，必然帶來效率的提升，進而帶來公司的效率提升，而效率提升的量變必然導致工作特性的質變——有完成工作到樂趣工作——Work Hard ,Play Funny。可以有更少的時間完成公司的要求任務，Make thing done，有更多的時間去創新，去Make thing happen。技術提升到底會帶來多大的效率提升？我以前聽過一個經驗的說法，是10倍。當然，信者恆信，不信者恆不信。但是最近我看到了一個證據。無意中，和我說，“，我現在一個打印管理器，兩個平臺，幾個工具的代碼共有40萬行”，我立刻來了興趣，查詢了下fx的代碼，共32萬行，8個人做，就是說其他項目的代碼量也應該差不了太多。僅僅是數量上看，的個人效率就可能是10倍數，何況他維護的代碼更加複雜，需要的設計和維護的成本也更加高。因此，這樣10倍並不算令人訝異。
我認爲，公司每個人都可以提高兩倍的效率，沒有就自己培養——只要有好的氛圍，大家都可以有機會更快的提升自己——比如說每週培訓，Scurm讓每個人都可以表達自己、比如通過重構建立流程，大家有機會討論令人費解的代碼，得到更好的設計。說實話，我認爲每個人都可以達到。利用更好的工具，有更好的流程和管理服務，有更好的技術素養，兩倍算什麼。我會有更多機會，有更多的人討論面向對象，討論更加高級的話題，“談笑有鴻儒往來無白丁”，這就是我的夢想版本。這是我孜孜以求的境界，爲此，我願意做這些推廣和普及的工作。花費大量的業務時間，看很多的代碼，閱讀很多的書籍和論文，花費時間去組織俱樂部，和微軟等公司溝通，如此等等。
msf就是一個案例。剛剛轉入trd，就開始做xiwa代碼。這樣的代碼是比較複雜的，boss也通過多種方式和我溝通，說這樣的代碼還是yqd做好一點，包括暗示，明講等等。我不爲所動，相信以trd的技術氛圍，msf雖然以往沒有這樣的平臺經驗，但是可以很快提升。事實正是如此。msf的進展和提升讓公司有了新的看法：大膽啓動新人，以有挑戰性的工作爲基礎，以技術氛圍和足夠的支持幫助員工成長，公司和員工共同受益。
fx作爲樣本，不過兩年時間，讓我看到了這種可能性是存在的，絕非空中樓閣。也許再過5年，公司每個人以技術爲樂。搞進銷存軟件並不可悲，也不會被認定是一定沒有技術的，要知道37Signls就是做項目管理軟件的，MF也是做什麼破音像租賃、HIS系統的起家，Thoughtworks給做的MIS系統的人提供諮詢，Kent Beck揚名立萬的是克萊斯勒工資系統，瞧瞧，瞧瞧。並且也要做MIS…,SAP說是ERP,其實還不是MIS一路的，人家可以有ABAP語言，我們也可以，我們現在都有平臺了，接下來不就是語言嘛——聲明型的。
我相信，我們也可以。
出去站了會，看到外部的蜘蛛人工頭站在樓上的護欄牆上，叼着菸斗，還往下看，聽到下面的蜘蛛人放繩子的聲音，心頭打顫。
低調低調。