N多年前微軟官網曾發了.Net下必備的十種工具，N多年過去了，世異時移，很多東西都已經變化了，那個列表也似乎陳舊了。而且，該文也只是對十種工具獨立的介紹，顯得有些羅列的感覺，是不是每個工具都是同等重要，工具與工具之間是否有聯系？等等，闡述得並不明確。
這裡，我想從另一個角崖，重新歸納一個更新的更實際的武器庫。更新，是因為有很多最近幾年才出來的工具/框架庫，更實際，是因為我自己的項目就完全依賴使用。
這個似乎是不言而喻的，只是從嚴謹的角度，也列在這。實際上，現在也有一個開源的IDE開發環境發展也不錯，叫SharpDevelop。我並沒有仔細看，不敢妄評。而我因要用到之後會講的Resharper，也迫使我只能用VS。
無論是從其名稱，還是實際功能，Resharper絕對稱得上利器，一旦你用熟了你就再也離不開它了。我去年換工作，很大一部分原因就是因為原單位不讓我使用Resharper。幾個面試，我也總在重復提出我這一要求。直至最新版本6.1為止，Resharper已經是個多面手。早期，它還只是個重構的工具，如今它是反編譯器(原來的Reflector.Net就用不上了)，還是個代碼審查工具(代碼規范審查)，還是代碼生成器(Code Smith又用不上了)，最後，它對鍵盤快捷鍵的組織使用，對無鼠標操作極其有益。一句話，Resharper能極大提高編碼的效率，利器更是重器。
這件武器其實分為兩部分，一個是Fluent，一個是nHibernate (這不是廢話)。nHibernate知道了解的人很多，就是一個ORM工具，而加上Fluent之後就知之甚少了。從功能上，Fluent只是在原來 ORM工具基礎加上一層封裝，以Fluent Interface形式提供了使用nHibernate的API。可是別小看這一層封裝，從使用體驗和效率提高方面，Fluent nHibernate有著卓越的功效。就我個人經歷，就是在Fluent nHibernate之後，才真正使用，喜愛上nHibernate本身。讓大多數人比較頭疼的創建映射XML文化，被全部C#文件代替，甚至可以完全省略。可以說這兩部分是一個完美的結合，後者提供強大的基礎功能，前者提供完美的使用接口。這不是一個成功軟件必須的兩個要素嗎?什麼是ORM，不會吧，放狗搜搜就知道了。我只想強調的是，不要把它僅僅看作一個功能庫，它更是個架構設計的利器。從架構的角度，它把業務域和數據層隔離，使得數據模型和業務域模型獨立設計成為可能。這一點的影響是非常深遠的。
啊呀，不得啦。上一武器，我一下子介紹倆，這一次白送四個。這也體現我寫本文的指導思想，從開發使用的角度來敘述而不是從工具提供者來還分。這四個套件在一起實在是太完美了！nUnit又是一個眾所周知的測試框架，它提供了測試的基礎功能和概念。MSpec從BDD的角度，封裝了一下nUnit，也可以說是重構了一下語法，使測試可具有可讀性，提供良好的測試組織結構，進而可以測試完了，直接生成一個完美的測試結果文檔。Rhino Mock也是一個熟客了，但是舊中有新，新的幾個版本也加入了一些可圈可點的新性能，如所謂AAA語法(Arrange, Action, Assert 這與MSpec的 Establish, Because, It關鍵詞完全契合)。而從我的角度，看到的亮點仍然是可讀性的改進。最後，AutoMock的出現又讓事情更加簡單了，連創建Mock對象的語句都省掉，只要你把依賴類的接口，在被測試的類的構造器中聲明傳入，AutoMock就自動為你創建Mock對象就，如同它的名字所表達的一樣自動Mock。當然，還有高級應用，暫不贅敘。
什麼，數據庫也算?是的，不過這裡SQLite不是我的產品數據庫，而是用它的內存數據庫做集成測試的工作，可以說是集成測試的利器。I\O讀寫歷來是性能的瓶頸，而敏捷編程對測試的高度依賴，也是對測試性能的高度要求。即使是高度覆蓋率的單元測試也仍然不夠，我們依然希望能在持續構建（CI）中，每次能自動運行集成測試。而如果要有真正獨立、干淨的集成/用例測試，最好是每個測試用例完全重建數據庫，重置測試數據，這樣的要求，只有內存數據才能得到良好的性能。使用SQLite證的內存庫後，不光集或服務器可以輕快的完成集成測試。開發人員本地，也把集成測試很快的運行完。這樣，我們的敏捷流程中不僅包括單位測試必須通過，甚至也包括了集成測試。它的名字叫用戶故事。
不過這個工具有個小小的問題，因為SQLite是基於C開發的，針對32位和64位系統，它分別發布了兩套控件，所以你必須根據自己的平台，3引用不同的Dll文件。而且，VS項目編譯設置還必須明確指明是x86還是x64，不能設為Any CPU。就為這個由題，我很是頭疼了幾天，最後才找到這個解決方安案。使用上，由於前面使用了Fluent nHibernate，除了配置，不用對代碼做任何改動。如果要改改了，也就不是真正的集成測試了，不是嗎?
如果你能一天就把代碼寫完，你就不需要源代碼管理，你能嗎?做為一個源代碼管理的新秀, Git的發展是極其迅猛的。我看好它，是它優秀的底層設計，優秀的業務模型. 如果要了解什麼是DDD，Git是一個非常好的典范。一般的源代碼管理，都是基於單個文件的版本控制，而Git一開始設計就是基於每個提交(代碼文件樹) 來追溯版本。你可能會不贊同我的說法，因為，很多代碼控制仍然提供了項目級的分支或者版本，其實那只是一個假像。VSS，SVN，TFS的最底層，都先是文件版本控制，在這個基礎之上，再提供項目版本的功能。而Gif卻恰恰相反。這個很重要嗎?是的，區別非常之大。引用DDD的思維，即然，從用戶的角度，代碼控制版本是基於文件樹的，為什麼你的業務模型卻不是呢?所以，我把耙VSS，SVN等的這種實現方式，看作打補丁/修補方式，總有一天，補了摞補了，至於最後，再也不能修補了。還有一點Git是分布式代碼管理庫。
噓（抹汗），總算到講到最後一個，已經寫得太長太多了，寫者累，看者煩。從CI工具的鼻祖CCNet升級到TeamCity之後，感覺確實不一樣，鳥槍換炮。為什麼要CI，好像不是我這一篇短文可以討論清楚的。
TC的好處，第一：是商業軟件並且免費，一般這兩點很難同時出現。當然有個限制，如果你只使一個編譯代理服務的話，這個對我來說已經足夠。第二：它對很多三方工具支持做得很好。如， nUnit, MSpec,Git等。最重要的是它是CI服務器!
