09 July 2005

我們新專案已完成 phase I 了,爽!

buildhistory

這張圖是我們 (六個人) 三個月來 pair 的成果,Y軸是每天 continuous integration 的 test case 的數量 (yes, 每天都是 success build)。四月初到四月中旬都是在分析需求,所以沒有增加 testcase。四月中開始則每天以20到30個 test case 不等,持續穩定的增加。最後七月總共1200 個 unit test。空白的部份則是週休二日。

雖然說穩定增加,其實裡面有兩週 (五月初和六月初)線是水平的。五月初那次是寫到400個test case 後發現架構有問題,所以整週都在做 refactoring (事後證明 refactoring 是對的) 六月初那次是大家去三天員工旅遊的啦~~~ 所以線也是平的 :-)

專案的平台是 Struts + Hibernate + Spring,除了JSP 之外,全部都寫了 Unit case。不知這樣的架構三個月 1200 個 test case 會不會算太少太慢?網路上從來沒看過相關文獻說....

我們第一個專案 是 Struts + Hibernate平台,共 1500 個 Test Case,當時 Struts 並沒有寫 Unit Test,所以大多數是 business, database 相關的 test case。你猜總共要跑多久?總共要 40 分鐘!寫到後來每次都要等很久..... 沒力啊.... 而這新的專案呢? 1200 個 只需要 4 分鐘 (包含建立資料庫) ,非常非常地快,開發的節奏完全不一樣了,讚!這都歸功於 Spring, Easymock, 與新版 Ant 的功能,強力推薦大家使用!

pair 的成員上次提過了,三個男 + 三個女的 (我們這男女開發員比例約為 1:1)

第一組:

  • (主導性高) 重度感染 Test 的 男 developer (症狀是每天逼大家寫 Test)
  • (主導性低) 中間程度之男Developer (但不熟. Hibernate /Unit test ... )

第二組:

  • (主導性高) 正值懷孕的中上程度女 developer (我沒寫錯,你也沒看錯,是 "懷孕")
  • (主導性低) 中間程度之女 Developer (配合度高)

第三組:

  • (主導性中) 男新人,不過底子夠,自學性強
  • (主導性中) 女 java 新手,背景是 procedure, database SQL 出身,不過她是整個 team 裡最熟 domain 的。

第一組曾發生過內亂,"Test 男" 嫌 "不熟男" 程度跟不上。氣的想自己寫算了。後來 "不熟男"發奮圖強,所以暫時先合解。"Test 男" 也改變了做法,pair 的時候都讓 "不熟男" 操作鍵盤,好好訓練。現在 pair 經過三個月後,"不熟男" 漸漸有點成績出來了。雖說獨當一面還不大夠,但是已經可以獨立維護程式了,終於變 "熟男" 了。

第二組在技術和經驗都沒什麼問題啦,她們後來也寫了最多的 test case。比較大的問題是 "懷孕女" 正值懷孕期間.... 還好跟她搭當的是我們 team 中配合度極佳的 女 developer,所以一切相安無事。不過 "配合女" 由於鍵盤都被主導性極強的 "懷孕女"搶走,所以對 pair programming 不是有好感,還是希望能自己寫,有自己的發揮空間。

第三組是個人最擔心的一 組... 因為兩個人都是第一次在這裡開發 java 專案,前兩組的都有過舊專案的 "教訓",所以都會採取比較正確的寫法。三個月下來,雖然 code 有一些暇疵,不過還是漂亮的完成了任務。"底子夠男" 脾氣比 "Test 男" 好多了,跟新手 pair 比較有耐心。"女java新手" 除了 web 那些有的沒的學不大起來之外,其他的邊學邊寫之下也頗成氣候的。而且她對 domain 熟,抓的方向會比較準。有趣的是 "女 java 新手" 開發完後的結論是:"還是 procedure 好寫......"

如果這次不是這樣 pair,比方說改成 "Test 男" + "女java新手",也許 "女java新手" 會比較了解為何 java 要這麼複雜,為何所有程式都要寫 test。又如將 "不熟男" + "配合女" 一起 pair,那自然就不會有衝突,"配合女" 也拿的到鍵盤,比較有機會發揮了。再將 "懷孕女" + "底子夠男" pair,那麼這一組的程式就不會有暇疵,"底子夠男" 可直接吸收 "懷孕女" 的經驗,而 "底子夠男" 脾氣較好,比較不會影響 "懷孕女" 的胎氣...

當然這樣想是事後諸葛啦,誰知道這樣的 pair 會不會有新的問題咧?

(上面那一段用的詞句有點奇怪,希望大家看的懂啦...)

Anyway, 個人對這次 pair 的感受是 --

  • pair programming 是最好的教育訓練的工具。原本高中低手都有,三個月後大家的水準馬上都拉上來了。未來我想 pair 的配對選擇方式應該會以教育訓練為第一個考量。
  • pair programming 減輕很多壓力!不論是設計或是撰寫,你都有 partner 可以商量,分擔責任,我們 team 裡沒有專職的 SA/SD,所以 pair design 適時的發揮效用。另外,想請假也有 "完整" 代理人。而且你不用花時間維護太多的文件,你隨時都有接班人,文件自然能寫精簡一點啦
  • 不用說,code quality 自然是標準水平以上了。如果這個專案是六個人分開寫,我真的不知道會變成什麼樣子... 就算三個月生東西出來了,大概也不能用吧....

總結。pair programming 不可能風平浪靜.... 有很多問題一一待克服.... 我們這先天的優點是男女比例一樣,我想如果是清一色的男性,那困難會大上很多。三個月下來,我相信我們 team 已經跨過 XP 的門檻了,相信未來的專案會繼續採用 XP -- 因為我們已經嘗到甜頭啦!


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>