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