Java 下的 team 開(kāi)發(fā)，一般采用 cvs(版本控制) + ant(項目管理) + junit(集成測試) 的模式：
每天早上上班，每個(gè)開(kāi)發(fā)人員從 cvs server 獲取一個(gè)整個(gè)項目的工作拷貝。
拿到自己的任務(wù)，先用 junit 寫(xiě)今天的任務(wù)的測試代碼。
然后寫(xiě)今天任務(wù)的代碼，運行測試，直到測試通過(guò)，任務(wù)完成
在下班前一兩個(gè)小時(shí)，各個(gè)開(kāi)發(fā)人員把任務(wù)提交到 cvs server
然后由主管對整個(gè)項目運行自動(dòng)測試，哪個(gè)測試出錯，就找相關(guān)人員修改，直到所有測試通過(guò)。下班。。。
先寫(xiě)測試，再寫(xiě)代碼的好處：
從技術(shù)上強制你先考慮一個(gè)類(lèi)的功能，也就是這個(gè)類(lèi)提供給外部的接口，而不至于太早
陷入它的細節。這是面向對象提倡的一種設計原則。
好的測試其實(shí)就是一個(gè)好的文檔，這個(gè)類(lèi)使用者往往可以通過(guò)查看這個(gè)類(lèi)的測試代碼了
解它的功能。特別的，如果你拿到別人的一個(gè)程序，對他寫(xiě)測試是最好的了解這個(gè)程序
的功能的方法。 xp的原則是 make it simple，不是很推薦另外寫(xiě)文檔，因為項目在開(kāi)
發(fā)過(guò)程中往往處于變動(dòng)中，如果在早期寫(xiě)文檔，以后代碼變動(dòng)后還得同步文檔，多了一
個(gè)工作，而且由于項目時(shí)間緊往往文檔寫(xiě)的不全或與代碼不一致，與其這樣，不如不寫(xiě)。
而如果在項目結束后再寫(xiě)文檔，開(kāi)發(fā)人員往往已經(jīng)忘記當時(shí)寫(xiě)代碼時(shí)的種種考慮，況且
有下一個(gè)項目的壓力，管理人員也不愿意再為舊的項目寫(xiě)文檔。導致以后維護的問(wèn)題。
沒(méi)有人能保證需求不變動(dòng)，以往項目往往對需求的變動(dòng)大為頭疼，害怕這個(gè)改動(dòng)會(huì )帶來(lái)
其他地方的錯誤。為此，除了設計好的結構以分割項目外（松耦合），但如果有了測試，
并已經(jīng)建立了一個(gè)好的測試框架，對于需求的變動(dòng)，修改完代碼后，只要重新運行測試
代碼，如果測試通過(guò)，也就保證了修改的成功，如果測試中出現錯誤，也會(huì )馬上發(fā)現錯
在哪里。修改相應的部分，再運行測試，直至測試完全通過(guò)。
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
