N多年前微軟官網(wǎng)曾發(fā)了.Net下必備的十種工具，N多年過去了，世異時移，很多東西都已經(jīng)變化了，那個列表也似乎陳舊了。而且，該文也只是對十種工具獨立的介紹，顯得有些羅列的感覺，是不是每個工具都是同等重要，工具與工具之間是否有聯(lián)系？等等，闡述得并不明確。

這里，我想從另一個角崖，重新歸納一個更新的更實際的武器庫。更新，是因為有很多最近幾年才出來的工具/框架庫，更實際，是因為我自己的項目就完全依賴使用。

Visual Studio

這個似乎是不言而喻的，只是從嚴謹?shù)慕嵌龋擦性谶@。實際上，現(xiàn)在也有一個開源的IDE開發(fā)環(huán)境發(fā)展也不錯，叫SharpDevelop。我并沒有仔細看，不敢妄評。而我因要用到之后會講的Resharper，也迫使我只能用VS。

Resharper---重構(gòu)必備

無論是從其名稱，還是實際功能，Resharper絕對稱得上利器，一旦你用熟了你就再也離不開它了。我去年換工作，很大一部分原因就是因為原單位不讓我使用Resharper。幾個面試，我也總在重復(fù)提出我這一要求。直至最新版本6.1為止，Resharper已經(jīng)是個多面手。早期，它還只是個重構(gòu)的工具，如今它是反編譯器(原來的Reflector.Net就用不上了)，還是個代碼審查工具(代碼規(guī)范審查)，還是代碼生成器(Code Smith又用不上了)，最后，它對鍵盤快捷鍵的組織使用，對無鼠標操作極其有益。一句話，Resharper能極大提高編碼的效率，利器更是重器。

Fluent nHibernate--- 域驅(qū)動DDD必備

這件武器其實分為兩部分，一個是Fluent，一個是nHibernate (這不是廢話)。nHibernate知道了解的人很多，就是一個ORM工具，而加上Fluent之后就知之甚少了。從功能上，F(xiàn)luent只是在原來 ORM工具基礎(chǔ)加上一層封裝，以Fluent Interface形式提供了使用nHibernate的API。可是別小看這一層封裝，從使用體驗和效率提高方面，F(xiàn)luent nHibernate有著卓越的功效。就我個人經(jīng)歷，就是在Fluent nHibernate之后，才真正使用，喜愛上nHibernate本身。讓大多數(shù)人比較頭疼的創(chuàng)建映射xml文化，被全部C#文件代替，甚至可以完全省略。可以說這兩部分是一個完美的結(jié)合，后者提供強大的基礎(chǔ)功能，前者提供完美的使用接口。這不是一個成功軟件必須的兩個要素嗎?什么是ORM，不會吧，放狗搜搜就知道了。我只想強調(diào)的是，不要把它僅僅看作一個功能庫，它更是個架構(gòu)設(shè)計的利器。從架構(gòu)的角度，它把業(yè)務(wù)域和數(shù)據(jù)層隔離，使得數(shù)據(jù)模型和業(yè)務(wù)域模型獨立設(shè)計成為可能。這一點的影響是非常深遠的。

nUnit+Machine Specification+Rhino Mock+AutoMocking--- 單元測試必備

啊呀，不得啦。上一武器，我一下子介紹倆，這一次白送四個。這也體現(xiàn)我寫本文的指導(dǎo)思想，從開發(fā)使用的角度來敘述而不是從工具提供者來還分。這四個套件在一起實在是太完美了！nUnit又是一個眾所周知的測試框架，它提供了測試的基礎(chǔ)功能和概念。MSpec從BDD的角度，封裝了一下nUnit，也可以說是重構(gòu)了一下語法，使測試可具有可讀性，提供良好的測試組織結(jié)構(gòu)，進而可以測試完了，直接生成一個完美的測試結(jié)果文檔。Rhino Mock也是一個熟客了，但是舊中有新，新的幾個版本也加入了一些可圈可點的新性能，如所謂AAA語法(Arrange, Action, Assert 這與MSpec的 Establish, Because, It關(guān)鍵詞完全契合)。而從我的角度，看到的亮點仍然是可讀性的改進。最后，AutoMock的出現(xiàn)又讓事情更加簡單了，連創(chuàng)建Mock對象的語句都省掉，只要你把依賴類的接口，在被測試的類的構(gòu)造器中聲明傳入，AutoMock就自動為你創(chuàng)建Mock對象就，如同它的名字所表達的一樣自動Mock。當然，還有高級應(yīng)用，暫不贅敘。

SQLite --- 集成測試必備

什么，數(shù)據(jù)庫也算?是的，不過這里SQLite不是我的產(chǎn)品數(shù)據(jù)庫，而是用它的內(nèi)存數(shù)據(jù)庫做集成測試的工作，可以說是集成測試的利器。I/O讀寫歷來是性能的瓶頸，而敏捷編程對測試的高度依賴，也是對測試性能的高度要求。即使是高度覆蓋率的單元測試也仍然不夠，我們依然希望能在持續(xù)構(gòu)建（CI）中，每次能自動運行集成測試。而如果要有真正獨立、干凈的集成/用例測試，最好是每個測試用例完全重建數(shù)據(jù)庫，重置測試數(shù)據(jù)，這樣的要求，只有內(nèi)存數(shù)據(jù)才能得到良好的性能。使用SQLite證的內(nèi)存庫后，不光集或服務(wù)器可以輕快的完成集成測試。開發(fā)人員本地，也把集成測試很快的運行完。這樣，我們的敏捷流程中不僅包括單位測試必須通過，甚至也包括了集成測試。它的名字叫用戶故事。

不過這個工具有個小小的問題，因為SQLite是基于C開發(fā)的，針對32位和64位系統(tǒng)，它分別發(fā)布了兩套控件，所以你必須根據(jù)自己的平臺，3引用不同的Dll文件。而且，VS項目編譯設(shè)置還必須明確指明是x86還是x64，不能設(shè)為Any CPU。就為這個由題，我很是頭疼了幾天，最后才找到這個解決方安案。使用上，由于前面使用了Fluent nHibernate，除了配置，不用對代碼做任何改動。如果要改改了，也就不是真正的集成測試了，不是嗎?

Git --- 源代碼管理必備

如果你能一天就把代碼寫完，你就不需要源代碼管理，你能嗎?做為一個源代碼管理的新秀, Git的發(fā)展是極其迅猛的。我看好它，是它優(yōu)秀的底層設(shè)計，優(yōu)秀的業(yè)務(wù)模型. 如果要了解什么是DDD，Git是一個非常好的典范。一般的源代碼管理，都是基于單個文件的版本控制，而Git一開始設(shè)計就是基于每個提交(代碼文件樹) 來追溯版本。你可能會不贊同我的說法，因為，很多代碼控制仍然提供了項目級的分支或者版本，其實那只是一個假像。VSS，SVN，TFS的最底層，都先是文件版本控制，在這個基礎(chǔ)之上，再提供項目版本的功能。而Gif卻恰恰相反。這個很重要嗎?是的，區(qū)別非常之大。引用DDD的思維，即然，從用戶的角度，代碼控制版本是基于文件樹的，為什么你的業(yè)務(wù)模型卻不是呢?所以，我把耙VSS，SVN等的這種實現(xiàn)方式，看作打補丁/修補方式，總有一天，補了摞補了，至于最后，再也不能修補了。還有一點Git是分布式代碼管理庫。

TeamCity --- 持續(xù)構(gòu)建必備

噓（抹汗），總算到講到最后一個，已經(jīng)寫得太長太多了，寫者累，看者煩。從CI工具的鼻祖CCNet升級到TeamCity之后，感覺確實不一樣，鳥槍換炮。為什么要CI，好像不是我這一篇短文可以討論清楚的。

TC的好處，第一：是商業(yè)軟件并且免費，一般這兩點很難同時出現(xiàn)。當然有個限制，如果你只使一個編譯代理服務(wù)的話，這個對我來說已經(jīng)足夠。第二：它對很多三方工具支持做得很好。如， nUnit, MSpec,Git等。最重要的是它是CI服務(wù)器!