我說(shuō)說(shuō)自己開(kāi)發(fā)一個(gè)Java程序常用的工具箱
我說(shuō)說(shuō)自己開(kāi)發(fā)一個(gè)Java程序常用的工具箱（僅為個(gè)人習慣）：
準備篇
1。白板（白板筆）。
1)需求階段和客戶(hù)討論問(wèn)題時(shí)分析、設計、客戶(hù)在這里自由交流大家對問(wèn)題的看法
2)在項目分析和設計階段用來(lái)進(jìn)行頭腦風(fēng)暴，是設計的最重要的工具。白板上畫(huà)的可以是UML圖，但也可以是項目團隊能夠理解的任意圖形，或者就是簡(jiǎn)單的線(xiàn)條、圖形都可以
3)無(wú)處不在的討論，任何時(shí)候對需求的理解和對設計的討論都在白板上進(jìn)行
一般公司里面經(jīng)常會(huì )出現白板筆太久沒(méi)用水用光的時(shí)候，所以我一般都要提醒后勤人員買(mǎi)好充足的筆，用完筆以后要蓋好蓋子。
2卡片（和圖釘）
1） CRC是除了白板以外第二重要的設計工具，這種卡片在中國很難買(mǎi)到，所以一般用文摘卡代替，CRC的重要作用在于可以進(jìn)行角色扮演，驗證設計的準確性。CRC的前面分別寫(xiě)責任和協(xié)作，背面可以進(jìn)行備注
2） 用戶(hù)故事卡，我回去定制一個(gè)泥印，直接蓋在空白的用戶(hù)故事卡上，這個(gè)卡片在需求階段可以任意傳遞、撕毀、重寫(xiě)、合、分裂，卡上有故事卡編號、優(yōu)先級、風(fēng)險評估和當前的迭代序號，用戶(hù)故事卡訂在一個(gè)大家都能看到的離開(kāi)發(fā)位置較遠的墻壁上
3） 任務(wù)卡，任務(wù)卡從故事卡分裂而來(lái)，用圖釘釘在開(kāi)發(fā)員的電腦旁邊
4） 編碼卡，主要紀錄需要實(shí)現的測試，需要注意的事項，等等，開(kāi)發(fā)人員不斷增加條目、劃去條目，是對一個(gè)人物而言的備忘錄和todolist
卡片一定要硬的，方便傳遞，有質(zhì)地感，有一定的厚度
***************
1。在CRC的扮演過(guò)程中，舉起一張硬卡片和一張軟軟的紙感覺(jué)不同
2。在撕卡片的時(shí)候，要有聲音有感覺(jué)，表示我們對需求的更改是非常歡迎的，不是說(shuō)些下來(lái)的東西就完全算數了
3。在需求過(guò)程中，卡片需要在客戶(hù)、程序員、分析人員之間傳遞，紙片太軟
4?？蛻?hù)需要根據價(jià)值把卡片按優(yōu)先級分堆，決定我們的迭代和發(fā)布，紙片不方便，容易遺漏和混淆，不太正式
5。故事卡可能一部分可能移到下一個(gè)迭代，不能在墻上貼了一段時(shí)間就變得破破爛爛
***************
3．大坐標紙（長(cháng)的直尺、各種顏色的筆）
我通常會(huì )在項目的進(jìn)行過(guò)程中記錄各種度量，這包括有效代碼增長(cháng)率、測試代碼增長(cháng)率、功能測試通過(guò)率、故事卡完成率、測試覆蓋率（具體工具在后面介紹），懸掛在比較高的位置，大家一眼能夠看到的地方
另外每個(gè)迭代的每個(gè)理想天都會(huì )檢查每個(gè)人任務(wù)完成的情況，延遲、提前、原因、重新估計時(shí)間、剩余實(shí)踐，根據不同情況用不同的顏色表達，畫(huà)在一張大白紙上，不夠的話(huà)可以慢慢接長(cháng)，貼在顯而易見(jiàn)的墻壁上
*************************
對于第3部分而言，這又是一個(gè)交流問(wèn)題，重在交流和整體感覺(jué)，而不是具體的數據
客戶(hù)、老板、項目開(kāi)發(fā)人員、管理人員各位都希望知道現在進(jìn)行的情況，開(kāi)發(fā)人員也需要對項目中其他人員地進(jìn)行情況有所了解，所以最好把這些東西放在最顯而易見(jiàn)的地方。每個(gè)相關(guān)人員都可以一眼感覺(jué)到項目的"溫度"
一般來(lái)說(shuō)，我檢查和度量的時(shí)間是在一個(gè)理想天，也就是3-4天的時(shí)間，一般采用的工具是JavaNCSS ，我有編寫(xiě)一個(gè)小小的工具，利用Javancss計算出源代碼的統計信息，按照時(shí)間為橫軸，畫(huà)出增長(cháng)的曲線(xiàn)，然后手工畫(huà)到墻上的大紙上。一些例子
1。產(chǎn)品代碼增長(cháng)率，這個(gè)增長(cháng)率應該在項目前期比較高，且比較穩定，如果某段時(shí)間的增長(cháng)率出現異常情況，可能在設計或實(shí)現過(guò)程中碰到了某些問(wèn)題。在項目后期應該逐漸降低（但不意味著(zhù)故事完成增長(cháng)率的下降，相反體現在故事增長(cháng)率和測試增長(cháng)率的相對提高），這是我們對重用的一個(gè)期望。代碼增長(cháng)率也是項目管理人員比較關(guān)心的問(wèn)題。
2。單元測試代碼增長(cháng)率，一直保持在比較穩定的增長(cháng)率，不同階段和產(chǎn)品代碼的增長(cháng)之間保持一個(gè)相對比率，例如從1：1到1.5：1到2：1，
3。代碼覆蓋率，用clover可以很方便地生成，CLover的歷史信息和增長(cháng)信息特別有用，當然還需要手工摘錄最重要的幾條曲線(xiàn)
4。用戶(hù)故事完成率，這是客戶(hù)需關(guān)心的東東，只有所有的用戶(hù)故事完成，才能號稱(chēng)迭代正確完成，不然寫(xiě)了多少代碼讀是沒(méi)有意義的
5。功能測試增長(cháng)率和Bug密度，功能測試反應的未通過(guò)的bug，這個(gè)最好是分界面、WEb曾或者數據庫層、模型層，統計在不同模塊的密度，這個(gè)Bug率最好加上估計的時(shí)間，例如1小時(shí)、2小時(shí)，半天等等。功能測試沒(méi)有100%通過(guò)是正常的，但是必須紀錄BUg的相對密度。
至于開(kāi)發(fā)人員的進(jìn)度模板，這個(gè)就比較復雜了，不同的項目也有所調整，我曾經(jīng)用XPPlanner產(chǎn)生過(guò)報表，但太靈水了，所以不得已用excel畫(huà)的，每1理想天更新一次，這是很重要的一個(gè)掌控工具，一個(gè)迭代周期內必須盡早估計到可能需要的延遲、客戶(hù)需求變化的調整、一些人提早或落后需要開(kāi)發(fā)人員之間相互調劑等等，據說(shuō)2003年生產(chǎn)力獎的XPOne非常好，但沒(méi)有評估版本，我每次只能用手工做。
這個(gè)象20個(gè)人的團隊大約要花上3-4個(gè)小時(shí)左右，所有人都要參加，要充分交流分析體現或落后的原因、要及時(shí)調整后面的估計，同時(shí)盡量讓每個(gè)人發(fā)表自己的意見(jiàn)，例如可能需要交換任務(wù)，重新調整任務(wù)的時(shí)間、加入新的任務(wù)、把某些任務(wù)延遲到后一個(gè)迭代、解決本天內的一些新發(fā)現的公共問(wèn)題等等。
當然，最后還是要抄到墻上去
*****************************
4、小桌子（香煙、綠茶、咖啡或水果）
工作一段時(shí)間，2個(gè)小時(shí)左右，開(kāi)發(fā)人員可以三兩成群地在小桌子（或者是吸煙區）旁邊抽煙、喝茶、咖啡或者水果，交流相互的心得、講講笑話(huà)、談?wù)勁龅降膯?wèn)題。很多問(wèn)題就在這里面談出來(lái)、解決、得到線(xiàn)索等等，團隊的氣氛經(jīng)常就是在這個(gè)時(shí)候變得慢慢融洽。
Wiki
我是Snipsnap的老用戶(hù)，所以項目開(kāi)發(fā)的時(shí)候還是用SnipSnap，SnipSnap的好處是使用簡(jiǎn)單，配置方便，涉及到項目開(kāi)發(fā)的具體應用，通用詞匯表的建立、概念的交流、工作方式的討論我喜歡在Wiki上進(jìn)行，Wiki也是一個(gè)項目知識庫實(shí)現的最佳方式，包括項目所需要的配置說(shuō)明、項目用到的書(shū)籍、文章和相關(guān)的討論
第二個(gè)Wiki是Fitness，這是做功能測試最好的工具之一
關(guān)于Wiki，我自己有項目管理中的新想法，不過(guò)很多相關(guān)的產(chǎn)品都不是開(kāi)源的，太貴，所以目前還沒(méi)有應用起來(lái)，等我自己了，呵呵
IssuerTracker
Jira,這是我少數選用的商業(yè)產(chǎn)品，舉我自己的感覺(jué)，這是Issuer里面No.1的產(chǎn)品，可惜和XP的項目計劃偏差較大，對于時(shí)間估計和流程配合不夠流暢。
為什么用Wiki的原因，我在另一個(gè)帖子已經(jīng)有些說(shuō)明，主要的問(wèn)題是WIKI的形式比較自由，能夠充分發(fā)揮想象力，不需要非常正式，但是又容易在開(kāi)發(fā)的過(guò)程中積累起很有意義的思考、文檔和模式?？偠灾?，是非常利于不拘形式的自由的交流。
Wiki的簡(jiǎn)單和目前很多WIKI的可擴展性，使得我們能夠把Wiki和其他軟件，例如Issuer，CVS等方便地結合起來(lái)。
Wiki軟件和Eclipse的結合可以產(chǎn)生很多對項目開(kāi)發(fā)有益的想法和幫助，雖然這一塊目前還不時(shí)有很多公司在做，但我覺(jué)得一些小小的結合就能產(chǎn)生很好的交流效果和文檔組織。
使用Jira的原因是它是面向開(kāi)發(fā)人員的一個(gè)tracker工具，在開(kāi)發(fā)階段它的表現要勝于其他跟蹤系統，它的靈活性和新近的插件機制也能夠方便我更好的擴展何時(shí)佩。
JUnit,這個(gè)沒(méi)什么好說(shuō)的，當然用法上自然是最偏向于KentBeck的用法。用Cactus測試感覺(jué)不是很方便。由于struts已經(jīng)不用了，用JUnit就能夠測試Webwork的Action，所以Web層我基本上已經(jīng)不測了。
Clover，雖然TDD的覆蓋率肯定是非常高的，但很多項目不做TDD的，我自己有一個(gè)小小的工具，自己用用還可以，但項目中沒(méi)辦法用， JCoverage是開(kāi)源的，紅工廠(chǎng)也有產(chǎn)品，但是我沒(méi)用過(guò)
用戶(hù)測試，目前我在第二個(gè)小項目中用Fit和Fitnesse，但沒(méi)有在大項目使用的經(jīng)驗。以前是自己寫(xiě)excel到數據庫轉換，用JUnit測的，比較麻煩
IDE，最早用的JBuilder，后來(lái)用的NetBean，在后來(lái)就是Idea，當初被Idea的refactoring功能之強大正酣，但有一次KentBeck在UMLChina聊天的時(shí)候說(shuō)起Eclipse，自此就沒(méi)有變過(guò)。吸引我的原因有很多，例如：
1）KentBeck為什么推薦Idea和Eclipse，而不推薦JBuilder，呵呵
2) EricGamma領(lǐng)導下做的，那還會(huì )有錯？，哈哈
3）free.我已經(jīng)被Borland公司的人搞得不行了
4) 界面風(fēng)格，當初的SWT表現還是非常優(yōu)異的
5）Eclipse的重構支持不弱于Idea
6） Eclipse對于程序員intention的理解稍稍弱于Idea，但確實(shí)也在不斷進(jìn)步
7) Eclipse很早就有內建的Ant和JUnit集成
Eclipse的CVS集成簡(jiǎn)直讓W(xué)inCVS變成一場(chǎng)惡夢(mèng)。能夠讓敏捷編程的配置管理策略非常容易地實(shí)現起來(lái)。CVS能夠真正成為團隊協(xié)作的一個(gè)基石。（這些策略我在自己的wiki上有很詳細的描述。最近因為一些原因，暫時(shí)無(wú)法瀏覽。）Eclipse的CVS集成也讓CVS和其他版本控制軟件之間的區別變得不是那么重要。
第一個(gè)完全構造在微核心上的開(kāi)發(fā)工具，做程序的好這一口，相信好的結構和體系有好的程序
綜合起來(lái)，Eclipse的很多設施方便XP的很多規則執行，而且又是免費的，沒(méi)理由不用呀
版本管理：CVS，當然CVS有很多多的問(wèn)題，例如沒(méi)有事務(wù)呀，不支持屬性呀，不支持移動(dòng)和重命名呀，但CVS是世界上用得最多的版本控制工具，那么多大小項目在用，那么多產(chǎn)品總是先在CVS上實(shí)現，再移植到其他軟件上。又是免費的。CVS最重要的特點(diǎn)當然是non-lock方式的開(kāi)發(fā)。Subversion可能會(huì )是我的下一個(gè)選擇。
CVS上我偶爾用的是CVSSTAT，但最近Fisheye異軍突起，可惜是要錢(qián)的。
構造：當然首先是ANT，一直想看看Maven，但好像太復雜了，試了一段時(shí)間，現在還是ANT.然后是集成構造的管理，我一開(kāi)始就用的是CC，就沒(méi)有再去想AntHill。CC除了可以用Email和Web通知之外，還可以用Jabber通知，我剛在用Jabber的eclipse插件，還沒(méi)有什么感覺(jué)。實(shí)際項目中還是以Email為主。
畫(huà)圖工具：我好像很少畫(huà)圖，除了在白板上，倒是寫(xiě)文章的時(shí)候經(jīng)常用Rose，畫(huà)出來(lái)的圖很漂亮，適合放在雜志上面或者放在網(wǎng)頁(yè)上.設計文檔里面的圖基本上也是用visio畫(huà)的，但通常很少，一般是針對整個(gè)項目核心的一些結構和設計。當然項目后期有的時(shí)候需要很多的圖，我一般用Rose或者用JRefactory逆向出來(lái)。
數據庫：數據庫總是需要兩個(gè)的，一個(gè)是production的，另外一個(gè)是workspace的，production的可不是我說(shuō)了算，如果要我推薦那就是SAPDB和Postgres了，當然Oracle和SQLServer是主流，我們也沒(méi)辦法的，但最近一個(gè)項目還在用Sybase。
workspace的數據庫是開(kāi)發(fā)用的，如果我沒(méi)有用Hibernate之類(lèi)可以方便移植的數據庫，那就只能是production數據庫了。但最近一個(gè)項目就出現問(wèn)題了，某公司當初是用Oracle開(kāi)發(fā)的，但現在去買(mǎi)要花20萬(wàn)，一開(kāi)始不想花這個(gè)錢(qián)，用SAPDB，不行,時(shí)間上也來(lái)不及了。如果是用ORM的，我一般現在用MYSQL
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
