交換程式設計

1. 交換程式設計

在軟體工程的開發方法中，有很多很著名也很有效果的開發方法，諸如原型、迭代、敏捷、RUP等。在談到交換程式設計的概念之前，我們應該首先提一下敏捷開發方法中的結對程式設計的概念。

 

1.1      結對程式設計

 “結對程式設計技術是一個非常簡單和直觀的概念：兩位程式設計師肩並肩地坐在同一臺電腦前合作完成同一個設計。同一個演算法、同一段程式碼或同一組測試、與兩位程式設計師各自獨立工作相比．結對程式設計往往只需花費大約一半的時間就能編寫出質量更高的程式碼， 但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早己習慣了獨自工作的時候、實施結對程式設計技術將給軟體專案的開發工作帶來好處．只是這些好處必須經過縝密的思考和計劃才能真正體現出來。”

——以上內容引自《結對程式設計技術》，原名為《Pair Programming Illuminated》，作者：（美）Laurie Williams, Robert Kessler。

 

下面我們分析一下結對程式設計的特點。

結對程式設計在很多專案中得到應用，也作為XP一個非常著名的觀點和做法被很多人大為推崇。

結對程式設計是兩個人同時做同一件事情的一種方法。表現上，會給人一種浪費一個開發人員的感覺，實質上，這的確是可以提升效率的。

同樣的這個做法，我在2002年在上海進行的一個類ERP專案中用過一次，當時在我做完許可權系統的全部功能後，和一個弟兄合作了一個模組，我們兩個人只用了三四天時間，就完成了這個新的模組的全部功能，這相對於我們此前做的功能模組來說，時間不到那些模組開發時間的十分之一。

 

1.2      交換程式設計

交換程式設計也是一個非常簡單和直觀的概念：兩位或者多位程式設計師輪流開發同一個軟體系統的同一個模組的不同階段的任務。交換程式設計的方式更合適的說法應該是交換開發，這種方式不僅僅在軟體專案中可以應用，同樣的事情也可以在其他研究開發型專案中得到應用。

 

這是一種更容易被人們接受的方法，在後面本文會做更詳細的分析，這裡只是提出它與結對程式設計的不同之處在於：它仍然採用傳統的一人一機的開發方式。

因此，它不會給人一種浪費開發人員的感覺，這種方式在2002年底到2003年間的專案中我進行了實際的操作。當時也只是基於團隊穩定和一種對於結對程式設計不被理解而不可實施的衝動才這樣做的一種試驗。

1.2.1 引入原因

在傳統的開發過程中，往往是一個人從一個模組的需求開始，然後作分析、設計、編碼、單元測試，然後才會交給第二個人（專職測試人員進行其他測試專案），這樣的開發過程會因為開發人員的變動而產生較大的影響。

而同時，結對程式設計的方式，對於開發人員人手嚴重不足的專案中，領導是不認可這種組織方式的，他們認為這會浪費很多的人力，一加一未必大於二。

而在當時引入這個方法的專案狀況如下：

這是電信MSS系統的核心業務系統部分，包括了規劃、設計、施工、驗收、財務、合同等多個重要環節和多個部門的業務。

開發人員數量較少，人員技能較為均衡，沒有水平超出其他人過多的技術人員。這個專案在最初評估的開發週期就是第一個版本在五個月內完成，而整個專案是至少要做上一年以上的，而最後的實際情況是，這個專案隨著不斷的升級和調整一直開發了三年多。

最初的開發團隊是十一個人，後來擴充套件到二十三個人，主要開發人員總數為十六個人，其中有四個人技術水平相對較高，另外的七個人技術水平相對較低但是也都有三年多的實際專案開發經驗，其中有三個是我2001年帶的三個應屆畢業生。

1.2.2 引入實施

由於開發團隊中沒有技術水平超出其他人很多的人員存在，因此技術方案的論證過程都是在大家的共同討論中制定下來的，只是在團隊整體控制上，當時我有相對較強的發言權，因此，在權衡了整個專案的實際情況後，我在需求工作完成後，告訴弟兄們一件事情，第二階段設計模型的開發大家交換來做。

剛開始很多弟兄不理解，因為相對而言我的開發經驗比其他人多了幾年，所以，當時我說的一些話，兄弟們還可以接受，於是，我就直接要求大家按照我的計劃進行執行。

在設計模型開發完成後，我再次要求大家進行了一次交換。

兩次交換完成後，我保證了每一個模組都有至少兩個人對這個模組十分熟悉，一方面不會因為人員的變動造成團隊的不穩定（這一點考慮相對較少，因為當時的團隊合作時間是比較長的，大家十分熟悉和互相都很瞭解），另一方面保證每一個模組的開發人員都能找到人進行討論，這增加了團隊內的溝通，方便了協調工作的進行。

因此在那個團隊的開發過程中，我們經常是大呼小叫，十分熱鬧，我們這個團隊無論走到哪裡，都是十分熱鬧的場景。所以，這也方便了一些新的開發方法的引入，和過程的實施考慮。

1.2.3 實施效果

由於專案沒有進行實際資料的度量對比，本文也無法從量化的資料上來說明問題，只能通過一些具體的事實來進行說明和驗證。

當時這個專案的模組從7個擴充套件到了11個，人員數量從11人擴充套件到了23人，我們在七個月內滿足了南方11家省級電信公司和集團公司的基本業務需求，從2003年4月到2003年12月期間，基本上完成了這些省公司版本的二次定製開發任務。

 

1.3      操作建議

交換程式設計中的操作會與其他過程有較大的差異，根據小子的經驗，建議在軟體工程實施的各個階段按照如下的方式進行：

需求工程，需求調研和需求分析進行輪流交換，輪流交換至少是三個以上的人進行互換，不是兩兩互換。

概要設計（分析模型）開發中，需求分析到概要設計也進行輪流交換。

詳細設計（設計模型）開發中，概要設計到詳細設計再進行一次輪流交換。

編碼實施啟動後，詳細設計到編碼的交換採用兩兩交換，注意這個時候不再採用輪流交換了。

 

1.4      操作建議分析

在編碼以前全部採用輪流交換的目的就是為了讓更多的人瞭解專案進展的全部內容，有利於增加團隊內的交流，使更多的人對專案所開發的內容熟悉，並能讓他們提出自己的觀點。也有利於使更多的人從更多的角度來研究某個系統模組所需要實現的功能和使用者需要解決的實際問題，不會因為某個人的定式思維而出現理解偏差造成對需求的理解不到位。

詳細設計到編碼的交換採用兩兩交換，這是因為前期需求已經基本上都穩定下來了，這時候不需要對使用者需求進行更多方面的理解，只需要進行實施，並進行純粹的編碼工作。這時候作輪流交換就不存在任何意義了，相反只能影響開發進度。

 

2. 優劣分析

這裡所提到的優勢都是和具體的開發方法相關聯的，大部分是相對於XP方法中的結對程式設計，同時也會分析它與傳統開發方式間的優劣。

 

2.1      開發時間“浪費”不明顯

1)     表現

這個開發時間“浪費”不明顯是相對於結對程式設計與傳統開發模式而言的。至少讓老闆沒有感覺到人員分配方式帶來了人員的浪費。

結對程式設計，大家都知道，需要兩個人共用一臺計算機，一套鍵盤，做同一個故事。這樣的開發方式往往會給人感覺浪費了一個人，雖然事實上未必如此，但是如果哪個專案經理第一次甚至說前幾次這樣做，估計大多數老闆都會表示反對的，因為他會感覺自己的技術人員只有一個人在做事情。

同樣，在2006年的敏捷中國開發者大會上，ThoughtWorks的總經理也提到了這個問題，他的解釋是這樣的：當兩個人合作三個月以上，則效率會超過兩個人單獨程式設計的效率！

注意：這裡有一個時間前提——三個月以上。

三個月這個時間未必是真實確鑿的時間分界線，它只是一個模糊的大概的時間範疇，如果兩個人配合的好，也許只需要兩個多月，如果配合不好，也許需要四五個月的時間，或者更長的時間……

我相信這樣的說法連Martin也不會反對的。

從這個時間界限上，大家可以看看國內公司的專案狀況，然後再繼續我們的討論。

2)     分析

①    專案情況

國內很少有時間限度較長的專案，大多數專案都是在三個月到半年時間內結束的。有些甚至只有一個月。

這樣的時間特性，將使得這個三個月的期限變成了一句空談，也就是說，當兩個人磨合好了的時候，專案已經結束了。

這時候，有人會說，下一個專案還可以繼續合作呀，好，那我們來看看國內專案團隊的人員變動情況，然後再繼續。

②    人員情況

國內大多數的公司都處於一種為了謀生而存在的狀態下，有很多技術人員都有三五個月就跳槽的經歷。

不僅僅是技術人員，往往公司也是這種狀態，很多公司就是為了某一個專案而建立的，老闆在招聘技術人員的時候，都是往最低限壓低技術人員的工資，當一個技術人員對專案瞭解到一定程度的時候，這個時間往往是在三個月到半年時間之間。

半年，或者一年，是一個人最容易發生跳槽行為的時候，因為這個人瞭解了公司的實質情況，如果老闆當時騙了人，那麼這個人必然要離開公司；如果老闆當時過分的壓低了他的工資收入，那麼這時候這個技術人員就希望能夠獲得加薪……除此之外，還有很多很多其他的因素，都會給人帶來未知的行為。

也可以說，國內很少有團隊成員能夠合作時間達到一年以上。

這樣的話，第一個專案磨合好了，第二個專案就是在考慮跳槽，第二個專案未結束，人就走了，這是我們平時很常見的現象。

這個時候做結對程式設計，效果就不會那麼明顯，因為在人員相對成熟的時候，人的心理髮生了較大的變化，工作的積極性和配合程度也遠遠不及剛剛進入公司的時候。

那麼結對程式設計在這樣的環境下還能進行下去麼？大家不用分析就可以知道了。

有人說，如果配合不好，那就換人結對，不一定非要這兩個人結對。這就要從專案組人數說起了。

 

③    專案組人數

在我所開發過的專案中，大概有不到一半的專案有十個人以上的開發團隊。最大的團隊開發人員是不到三十人，這二十多人還要分成幾個組，每個組也就五六個人而已。

在這種情況下，結對的問題就出現了，在組內的你只能和這麼三五個人結對，是不是都很容易配合起來呢？這個事情很難說。

配合不好怎麼辦？換人？換專案？還是換公司？當然，如果配合了三個月還配合不好，站在公司的立場上，是肯定要考慮開除掉某人了，至少也要將他降薪或者調離這個專案組，因為公司承擔不起這麼大的風險，專案經理更是在擔著風險，因為結對程式設計的事情老闆本來就不太樂意看到，本來老闆就有意見，而專案組如果發生了這樣的配合力度很差的情況，專案經理的處境可能就非常危險了。

 

綜合上面這三個方面的情況，我們可以得到如下的結論：

結對程式設計在中國這些短小專案過多的情況下是不太適合的！結對程式設計其實更適合一些相對人員較為穩定的開發環境，否則，三個月的低效率配合時間會讓老闆將專案經理的腦袋當球踢的。

但是，結對程式設計還是有其好處的，比如，提高專案組的穩定性，當一個人離開後，另外一個人可以很快地將新人帶到位，專案組不會因為人員變動而發生較大的風險問題。

同時，結對程式設計提高了程式設計師之間的交流，團結了專案組內成員，同時容易形成人月神話中提到的膠凍團隊的效果。

另外，在三個月後還是有效率提高的情況發生，的確能夠帶來很好的效益的。

這時候，交換程式設計就帶來了很好的效果，一則，沒有老闆擔心的兩個人做一件事情的風險，同時，增加了專案組內成員的溝通交流，也提高了團隊的穩定性。

那這個問題如何解決？這裡，我們不妨來看看交換程式設計是如何提高專案組穩定性的。

 

2.2      專案組穩定性提高

1)     表現

在我前面的例子中可以看到，一個模組至少有三個人對他很熟悉，因此在後面的開發過程中，無論哪個人發生變動，都不會影響這個團隊的穩定性，所有的任務都能夠很好的延續下來。

每一個系統的模組都會至少按照階段數量（不同的專案會有不同的開發週期，同時也就有不同數量的人會對這個模組十分熟悉）分給不同的人來進行開發。

如果和結對程式設計配合起來使用，則將會使得對同一個模組瞭解的人數達到一般交換程式設計的兩倍人數。

 

2)     分析

有了這樣的對每一個模組都很熟悉的人員數量的存在，團隊的穩定性就會表現出來，任何一個人的變動，或者少數人員的變動都不會對團隊和開發進度產生較大的影響。

因為隨時都可以有其他人來接替這個發生變動的人的全部工作，也很容易培養新人進入到團隊內來進行工作。

 

2.3      團隊內沒有絕對高手時交換程式設計更適合

1)     表現

當團隊內沒有絕對高手存在時，也就是說，系統的架構設計將是更多的人一同討論出來的，並在開發過程中不斷的修改和調整。

 

2)     分析

沒有絕對高手存在，系統架構設計就不能夠在系統進行分析設計前完成，而同時架構的不穩定，就無法更好的安排任務計劃和制定故事，這些都會影響到整個系統的開發進度和過程，同時，敏捷程式設計所倡導的很多做法就無法在這個大前提下來進行實施。

國外能夠很好的採用敏捷的做法來實施專案的一個原因是，他們有很多工作在一二十年經驗的開發人員，這些人員的經驗積累是非常重要的，他們可以更好的在專案開始的前期對專案進行整體的控制和把握，同時做好專案計劃，制定好任務故事，而這一點，在國內，尤其是中國的軟體公司中還不具備這個條件，因此，很多專案我們都處於的狀態類似於我前面所舉的電信專案的團隊情況，甚至情況比那個團隊還要差得很多。

 

2.4      團隊內交流增加

1)     表現

前面已經提到：“因此在那個團隊的開發過程中，我們經常是大呼小叫，十分熱鬧，我們這個團隊無論走到哪裡，都是十分熱鬧的場景。”

這種頻繁的交流，無形中使得團隊的凝聚力提高，相互之間的關係和合作也都更為密切。

 

2)     分析

如果是一個人從頭到尾開發一個模組，他就幾乎不需要和團隊內非管理人員進行交流，甚至在某些情況下他只需要和客戶做好溝通就足夠了。而這時候，及時進行了同行評審，這個技術人員也可能會認為：那麼兩三天的時間，這些人不可能瞭解這個系統模組的內容。這種評審也就容易流於形式而無法得到真正的重視。其他人也會認為評審是浪費自己的開發時間，於是評審到了一定程度就會成為可有可無的狀態。

如果有較多的人蔘與了這個模組的前後期分析和開發，每一個階段，都可以找到別人來進行討論，同時，在評審時，對這些人提出的意見也就更容易接受——因為他至少會認為這幾個人比他更早的介入這個模組的分析，在某些程度上會比自己瞭解的更為深入。

 

3. 深入討論

交換程式設計的應用方式是有其適用環境的，另外，在小子的實踐和研究中，小子還要建議如果團隊合適，可以考慮與結對程式設計配合使用。

 

1)     適用環境

這種開發方法的適應性較強，這裡分為團隊狀況和專案情況兩個部分進行一些說明。

 

①    團隊狀況

交換程式設計適用於人數超過兩個人的開發團隊，因為交換一次至少也需要兩個開發人員。

大的團隊也可以應用交換程式設計的方式，來進行專案開發。

要求團隊內的成員有一兩個具有兩三年以上開發經驗的，就可以採用這種方法進行團隊開發——而對於一般的專案，哪怕沒有什麼技術難度，這也是最最近本的人員技能要求了。

 

②    專案情況

專案規模不限，開發週期的適應性也較強，對於任何型別的專案都可以適用。

 

2)     與結對程式設計配合使用

如果領導比較認可結對程式設計的開發方式，這個時候，您引入交換程式設計也會帶來同樣的好處：

①    團隊穩定性：

至少有一點，團隊的穩定性從對系統業務模組熟悉的人數上來看，增加了一倍。

②    團隊凝聚力：

團隊成員之間的交流會更為頻繁，這樣就會更多的降低因為少數人的思想和考慮偏差造成對使用者需求理解不足等問題。

 

有了上述的情況表現，也使得團隊的規範化操作能力更強，也可以使得很多問題能夠在有效的溝通中的到解決。

 

4. 綜述

由此可見，交換程式設計的存在是有其道理的，沒有用過的朋友，不妨嘗試一下，至少對您的團隊沒有什麼傷害和大的變動，可以逐漸推進。

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