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