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