[技術討論]06年12月11日關於結對程式設計實踐的一段對話

qingrun發表於2008-01-30

對話內容

海皮-  說:
呵呵,我覺得結對程式設計最大的阻力在於說明經理這樣是可以提高效率的
青潤 說:
呵呵,其實在我所看到的論文中,有些資料很充分的論文,說明結對變成並不能始終保證具有較高的質量和較好的效率。
青潤 說:
而且,國外所做的所有的研究都是建立在結對的兩人組和一個人的開發組之間的對比,如果通過結對的兩人組和兩個單人開發組進行對比,結果更是未必。所以,我目前不認為結對一定能始終提高效率,但是,我覺得,他應該能夠在某一個階段,或者說專案進行的某一個階段內提高效率提高質量。
青潤 說:
只是這個階段需要實踐來作驗證。
海皮-  說:
我們的技術總監認為,只有當結對的兩個人的業務能力相差無幾的情況下,才能提高效率。我們經理認為,這種方式沒法寫到公司的月報和年終總結中。
青潤 說:
那些資料很充分的論文來自德國,德國人做事的嚴謹程度也是可以說明問題的。
青潤 說:
我覺得有可能我給你們公司做個結對實踐的交流吧。否則,很多東西會出現問題的。
青潤 說:
你們技術總監的這種看法僅僅是建立在感性的基礎上的,他絕對沒有實踐過,而且沒有作過對比試驗,所以,這樣的話,其實是有點不負責任的
海皮-  說:
我想結對程式設計可能減少單元測試時,Bug的數目,
青潤 說:
這也是有條件的。
海皮-  說:
我們確實沒有試驗過
青潤 說:
想,是沒有太多現實意義的,想了以後,要去做,這才有可能來作驗證。
海皮-  說:
有道理
青潤 說:
其實從實際結對的感受來說,我認為,經驗較為豐富的坐在旁邊,而經驗較弱的動手編碼,這樣才能提高質量,減少一次編碼的bug率。而從效率上來說,只有兩個經驗相等的人結對才有可能做到。
青潤 說:
這是我02年實踐的一個總結。
加密助手 說:
--- 系統提示:以下會話未被加密 ---
海皮-  說:
一個有經驗的人每天對小組內的新手的程式,做一次走讀,是不是也可以起到減少Bug的目的
青潤 說:
不能。這樣做是無效的。
青潤 說:
因為他根本沒有時間,也沒有足夠的精力把所有的都思考到位。[注1]
海皮-  說:
我打算這麼做,因為我的小組新手太多。
青潤 說:
那樣做反而會浪費這個人,不如讓這個人自己去做開發。呵呵
青潤 說:
這個原因和我前面那個結對方式的原因,你自己考慮考慮,應該能想明白。
海皮-  說:
呵呵,可是我一個人不能把所有的活都幹了。
青潤 說:
原因你自己去思考。我告訴你的那個結論是必然的,當然可能會有例外,比如這個人是神仙,那就不在此列了。
海皮-  說:
OK,謝謝

青潤 說:
不客氣。 

幾個總結

1、提高編碼質量減少一次編碼bug率的結對方式:經驗較為豐富的坐在旁邊,而經驗較弱的動手編碼,這樣才能提高質量,減少一次編碼的bug率。

2、提高編碼效率的結對方式:而從效率上來說,只有兩個經驗相等的人結對才有可能做到。


3、國外所做的所有的研究都是建立在結對的兩人組和一個人的開發組之間的對比,部分文章的結論是結對程式設計不能始終保證開發質量和效率始終高於單人程式設計。

4、如果通過結對的兩人組和兩個單人開發組進行對比,結果更是未必。所以,我目前不認為結對一定能始終提高效率,但是,我覺得,他應該能夠在某一個階段,或者說專案進行的某一個階段內提高效率提高質量。

[注1]:

2006年12月11日補充:應該說新手過多的時候,這種指導只能做到對簡單問題的核查,對於業務邏輯複雜或者程式碼質量上是沒有什麼提高的。更不可能達到結對變成或者交換程式設計的效果——但是,一個有經驗的人輪詢多個新手進行開發的方式應該是國內公司十分常見的模式。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/257598/viewspace-165678/,如需轉載,請註明出處,否則將追究法律責任。

相關文章