2006年JOLT大獎（http://www.）的得獎名單：

企業(yè)項目管理：WelcomRisk 2.6（Welcom）

缺陷跟蹤、變更與配置管理：Perforce SCM 2005（Perforce）

設(shè)計與建模：Lattix LDM 2.0（Lattix）

項目質(zhì)量管理：Rally 5.6（Rally Software Development）

測試工具: VMTN Subscription 2005（VMware）

不知道他們長什么樣子嗎？沒所謂了，工具從來就亂花迷眼，但花哨的工具未必適合自己的團隊?？傄磧翥U華的總結(jié)出一些最必要的，能提供最大輔力加持的工具。
參見《死亡中旅》2nd 第x章--最小工具集.

1.版本管理工具

    有沒有版本管理，可以作為項目到底有沒有推行軟件工程管理的一條華麗的分隔線。
   因為現(xiàn)在是2006年了，我們選的是Subversion。

  客戶端工具：小海龜（http://tortoisesvn./）。這個CVS版的姊妹工具以前就號稱WinCVS殺手了，與Window Explorer右鍵的整合，摒棄了必須專門跑一個Client的傳統(tǒng)。

  文本比較與合并工具：小海龜里集成的TortoiseMerge。除了Update和Commit外，查看歷史版本差異，合并版本沖突是大家最常做的事情了，所以工具也一定要用適合的。

  Web瀏覽代碼：Trac（http://www./trac/），完全合乎讓人Pleasure標準的Web版代碼展示工具。能夠方便的查看，Search代碼，觀察倉庫的提交日志。

如果團隊里依然用CVS的話，相對應(yīng)的推薦套件就是：

l         客戶端：小海龜（www.)

l         差異比較工具：WinMerge

l         Web代碼瀏覽工具：Fisheye

l         賬號管理工具：CVSTrac

2.項目計劃，任務(wù)分配，需求變更管理，Bug管理工具
    偶然的，我發(fā)現(xiàn)自己把這些都交給了JIRA完成。

    項目計劃，任務(wù)分配，進度跟蹤，需求變更管理，Bug管理幾乎就是PM的全部工作了。
    以前總有很多軟件分開來管理這些問題，同一問題經(jīng)常要Copy Paste好幾個軟件。
    但如果你的團隊的項目計劃是XP plan風(fēng)格 而不是MS Project。
    那恭喜了，一個JIRA就可以完成所有任務(wù)。 
    但MS Project實在深得各位老板厚愛，所以我們會做一個粒度很粗的Project來應(yīng)付老板、開會和監(jiān)理，讓他們大概了解項目的計劃和進度。而采用敏捷編程的計劃風(fēng)格，靈活的向團員分配具體任務(wù)。
 
    看Jolt的獎項設(shè)置，也可以看到這種把N種項目管理工具組合歸并的趨勢，去年的“Change and Configuration Management Tools”和“Test-Defect Tracking Tool”，已經(jīng)合并成“Defect Tracking, Change and Configuration Management”

3. 設(shè)計建模工具

   雖然程序員都不太喜歡代碼以外的任何東西，當(dāng)然也包括UML圖。但實踐證明敏捷編程也不能完全拋棄設(shè)計，如果將UML圖用于純粹的交流工具而不是MDA一類宏偉愿望的話還是挺有用的，比如靜態(tài)Class圖和順序圖是我最經(jīng)常畫的東西。

    有很多明星級的工具可以畫這些圖，但我某天發(fā)現(xiàn)，一個很小巧的工具Jude（http://jude./jude-web/index.html）已經(jīng)可以把這兩種圖畫得很好。大家都可以在使用內(nèi)存怪獸般的設(shè)計建模工具時，尋找屬于自己的袖珍玲瓏版工具。

   另外，如果要畫流程圖。我喜歡SmartDraw多過Visio。因為SmartDraw有很多色彩鮮艷，配色好看的模板，現(xiàn)成又好看的東西才是第一選擇。

4.開發(fā)環(huán)境
曾幾何時，Visaul C++6.0是我認為最完美的開發(fā)環(huán)境，而隨著IDEA和Eclipse的不斷升級，我們的個人品味與懶惰程度也在共同提高。同時，Eclipse也依靠它無敵的Plugin編隊，將自己的風(fēng)格逐一推向Java、C++、PHP、Python和Ruby等領(lǐng)域，有一統(tǒng)江湖的趨勢。

重構(gòu)（二級）

即使團隊用得最多的只是Rename、Move、Extract Method等幾個基本動作，Java EE架構(gòu)里牽一發(fā)動全身的事情也太多了，重構(gòu)會幫你把所有事情做干凈，所以我現(xiàn)在已形成依賴，如果不用重構(gòu)，隨便改一樣?xùn)|西，肯定造成一堆東西編譯不過或者Web應(yīng)用啟動失敗。IntelliJ IDEA作為第一個支持重構(gòu)的工具，已經(jīng)一路高歌把重構(gòu)的概念深入到JSP、XML、JavaScript和CSS等，實在是相當(dāng)聰明。

Flying Error提示和自動修正（二級）

Flying Error提示在Java IDE里已經(jīng)逐漸成了標準配置，有錯了馬上提示就地更正，不需要積了一堆錯誤等到編譯時才慢慢查看Error Message排錯。又是IDEA，不但提示錯誤，還會提出幾種可選的修正方案，你點一下就會幫你自動修正。比如一個函數(shù)會拋出必須進行處理的checked異常，你如果調(diào)用了這個函數(shù)，IDEA就會提示你“是在調(diào)用的地方進行Try Catch呢，還是在外層函數(shù)聲明Throws這個Exception？”你選擇之后就會幫你自動完成，感覺非常貼心。

Smart Complete（二級）

比如現(xiàn)在要輸入myFirstBook.setPublishDate（publishDate)這句代碼，上一代的IDE在輸入myBook.后，會彈出下拉菜單顯示Book類的所有函數(shù)讓你選擇。

而新一代的IDE，AI都高得嚇人，總能通過變量類型與上下文的名字猜出你想輸入的內(nèi)容，比如“my＋熱鍵”就能生成myFirstBook，“(＋熱鍵”就能生成publishDate。如此Smart的結(jié)果，就是我編碼的過程中熱鍵不斷，成了徹底的懶人。

Debug Java EE應(yīng)用（二級）

Web開發(fā)者一般用System.out或者Log4j來顯示調(diào)試信息，但對于曾經(jīng)桌面編程的程序員來說，直接進入調(diào)試模式，單步跟蹤程序執(zhí)行路徑，想看哪個變量就看哪個變量，才是天經(jīng)地義的事情。慢慢的，這一代的IDE也已經(jīng)覺醒，通過與Application Server的集成，可以在JSP，甚至第三方類庫的源代碼如Spring Framework的HibernateDAOTemplate里設(shè)置斷點，然后單步執(zhí)行，察看變量的變化。

如果左看右看，其他語言的IDE都很難符合上面的要求，不妨等待Eclipse的強大平臺，一個個插件的慢慢統(tǒng)一。

 5.團隊IM工具和共享文件夾

   關(guān)于交流工具，從前是言必稱Email的。而隨著社會的進步，現(xiàn)在更提倡交流的即時性，因此，“Face to Face”的交流被作為首選，早上15分鐘的短會， IM工具被作為與Email同等重要的手段。

   說起IM工具，很多公司都會選擇嚴肅的MSN而不喜歡QQ。但我還是喜歡QQ的群功能，而且雖然提倡交流的即時，但避免打擾對于開發(fā)者也很重要，QQ 新版的“來消息時只顯示消息條數(shù)”能起到同樣的免干擾作用。

   最后是知識庫，Wiki有一個曾經(jīng)是優(yōu)點的缺點——Wiki語法。它的簡單只是對于那種用寫字板寫網(wǎng)頁的高手來說的，大部分人寫文檔的時候還是喜歡所見即所得的編輯。而且，Wiki語法與html不兼容，造成了知識庫與互聯(lián)網(wǎng)世界的鴻溝。不過好在Cofluence 2.0終于有了所見所得的編輯器，也可以棄用Wiki語法而直接使用html編輯了。

其他項目工具包括紙，筆，足夠大的白板，隨時可用的會議室。還缺了什么？ 代碼自動生成工具中也沒有最趁手的。

注：本文的全文已經(jīng)發(fā)表在《程序員》雜志2006年第5期，更詳細的內(nèi)容請購買雜志，哈哈--泰穩(wěn)過午不食 說。