級別: 初級

林星, 項(xiàng)目經(jīng)理

2003 年 9 月 01 日

結(jié)對編程的根本思路是改善開發(fā)團(tuán)隊(duì)內(nèi)部的溝通質(zhì)量。在實(shí)際情況中，不同的開發(fā)團(tuán)隊(duì)面臨著不同的溝通問題。那么，該如何找到一個(gè)共通的指導(dǎo)思路呢，又該如何根據(jù)實(shí)際的情況進(jìn)行調(diào)整呢？

成本權(quán)衡和策略選擇

從上一篇文章的討論中，我們可以了解到，由于現(xiàn)實(shí)的因素，做到理想化的結(jié)對編程往往會(huì)有很大的阻力。這個(gè)時(shí)候，我們可以根據(jù)實(shí)際的情況進(jìn)行調(diào)整，選用不同的方式。但我們?nèi)绾卧u估這些方式的成本呢？設(shè)計(jì)結(jié)對，測試結(jié)對，復(fù)審結(jié)對等等的變通方式都存在一個(gè)問題：就是表面上看起來它們似乎既達(dá)到了結(jié)對的效果，又節(jié)省了成本。但是實(shí)際上，這個(gè)成本并沒有節(jié)省，而是轉(zhuǎn)移了。

注意到，這個(gè)過程中，A和B不進(jìn)行結(jié)對編碼而節(jié)省的時(shí)間其實(shí)是轉(zhuǎn)移到復(fù)審上來了。當(dāng)然，復(fù)審上花費(fèi)的時(shí)間可能要比編碼的時(shí)間短得多。但是我們還必須看到，如果B變更后的設(shè)計(jì)也存在缺陷，A和B仍然需要花費(fèi)一定的時(shí)間來改進(jìn)設(shè)計(jì)和實(shí)現(xiàn)，這種情況也是有很大的可能性發(fā)生的。

對結(jié)對編程的成本進(jìn)行討論并不是要下一個(gè)定論。對于不同的組織而言，這個(gè)成本是不確定的。對于某一些組織而言，理想的結(jié)對編程也許非常的合適，但對于另外一些組織來說就未必。重點(diǎn)在于，必須找到一種方法，使得團(tuán)隊(duì)之間的溝通能力得以增強(qiáng)。

不同團(tuán)隊(duì)進(jìn)行結(jié)對方式設(shè)計(jì)的時(shí)候的標(biāo)準(zhǔn)只有一種，就是如何改進(jìn)溝通質(zhì)量。不同的團(tuán)隊(duì)有著不同的溝通問題。找到這個(gè)溝通問題，才能夠?qū)ΠY下藥。有這樣一個(gè)軟件組織，他貫徹結(jié)對編程的思路很簡單，就是為了減小人員流動(dòng)對業(yè)務(wù)的影響。經(jīng)過研究，我們發(fā)現(xiàn)這個(gè)組織有這么一些特點(diǎn)：產(chǎn)品經(jīng)歷過數(shù)代的演化，結(jié)構(gòu)復(fù)雜；開發(fā)人員僅對自己負(fù)責(zé)的模塊比較了解，全面掌握系統(tǒng)的人極少；產(chǎn)品擁有固定的客戶群，客戶時(shí)常有修改的需求；任何一個(gè)開發(fā)人員的流失都意味著他負(fù)責(zé)的模塊在一段時(shí)間內(nèi)無人接手；相對于模塊無人負(fù)責(zé)的尷尬境地，增加一個(gè)開發(fā)人員的成本是可以接受的。在這樣的一種情況下，該組織要求任何一個(gè)模塊都必須有兩個(gè)開發(fā)人員負(fù)責(zé)。事實(shí)上，采用了這一方法之后，人員并沒有翻倍，因?yàn)榫S護(hù)老產(chǎn)品和開發(fā)新產(chǎn)品的工作是并行的，而且，同一個(gè)開發(fā)人員不僅僅只負(fù)責(zé)一個(gè)模塊。雖然人員增多了，但是客戶的滿意度提高了，而開發(fā)力量也同時(shí)得到了增強(qiáng)，這個(gè)結(jié)果還是令人滿意的。

可以看到，在這個(gè)例子中，結(jié)對的方式并不是XP中所描述的結(jié)對編程，它只是一種組織形式，但是在解決溝通問題上，兩者的思路是相類似的。同樣的，我們?nèi)绻Ｍ谧约旱慕M織中應(yīng)用結(jié)對，那么分析自己組織的溝通瓶頸的工作是少不了的。

設(shè)計(jì)結(jié)對

設(shè)計(jì)結(jié)對的含義是某一模塊的設(shè)計(jì)由雙人完成，這里的設(shè)計(jì)并不是大規(guī)模的軟件設(shè)計(jì)（對于大規(guī)模的前期設(shè)計(jì)而言，我們更傾向于讓團(tuán)隊(duì)設(shè)計(jì)，請參看敏捷架構(gòu)設(shè)計(jì)一文），而是在某個(gè)特性在編碼之前的設(shè)計(jì)，這種設(shè)計(jì)的特點(diǎn)是持續(xù)的時(shí)間很短（只有幾個(gè)小時(shí)或是幾十分鐘），但是對于整個(gè)代碼的質(zhì)量而言非常的重要，因?yàn)槲覀冃枰ＷC設(shè)計(jì)符合架構(gòu)的原則，以及設(shè)計(jì)的靈活性，一致性等等，還需要保證設(shè)計(jì)的性能和速度。而某個(gè)特性在設(shè)計(jì)完成并進(jìn)入編碼之后，這部分特性就已經(jīng)確定下來了。因此這種小規(guī)模的設(shè)計(jì)往往是軟件開發(fā)中比較重要的細(xì)微點(diǎn)。在設(shè)計(jì)上配置雙人，能夠有效地提高代碼質(zhì)量。這種結(jié)對的思路是把成本花在關(guān)鍵的部件上，但是小規(guī)模設(shè)計(jì)結(jié)對的具體表現(xiàn)往往是兩個(gè)人對某個(gè)問題的某種看法，他并不能以代碼或是模型的形式來體現(xiàn)，對非編碼者一方的約束比較小，而代碼實(shí)現(xiàn)很可能和設(shè)計(jì)有所出入，這樣，非實(shí)現(xiàn)者也難以獲得這方面的知識。這種方式如果單獨(dú)使用，容易演變成一種形式，效果并不是很好。因此，我們需要其它結(jié)對方式的配合。

測試結(jié)對

這里的測試結(jié)對專指單元測試結(jié)對。結(jié)對的基本思路是A和B就類輪廓（類結(jié)構(gòu)和公有方法）達(dá)成一致后，A編寫測試代碼，B編寫代碼來滿足測試。如果B對設(shè)計(jì)的理解有誤，那么代碼一定通不過測試，如果A對設(shè)計(jì)的理解有誤，B必須通知A重新編寫測試。如果對XP的單元測試的改變非常熟悉的話，采用這種方式會(huì)有不錯(cuò)的效果。首先，測試代碼本身就是小規(guī)模設(shè)計(jì)，而且它以一種規(guī)范的編碼形式反映出來。只要測試代碼足夠優(yōu)秀，它可以捕捉很多的設(shè)計(jì)缺陷。其次，這種方式是測試有限的一種變體，但是其效果要優(yōu)于單個(gè)人的測試優(yōu)先。因?yàn)橐粋€(gè)人思考測試和設(shè)計(jì)難免有考慮不周的地方，但是如果兩個(gè)人來考慮的話，測試往往能夠發(fā)現(xiàn)出更多的問題或缺陷。剛開始使用這種方式的時(shí)候，可能會(huì)有些不習(xí)慣，但是熟悉之后就會(huì)比較順利。

復(fù)審結(jié)對

設(shè)計(jì)結(jié)對和測試結(jié)對都是在編碼活動(dòng)開始之前進(jìn)行結(jié)對活動(dòng)。但是復(fù)審結(jié)對則是在編碼活動(dòng)完成后進(jìn)行的。A在B完成代碼之后，需要對代碼進(jìn)行復(fù)審，復(fù)審的內(nèi)容包括，代碼是否體現(xiàn)了設(shè)計(jì)的意圖，代碼中是否存在缺陷，代碼是否滿足需求，代碼是否符合一致性原則。一般這種復(fù)審都屬于同級復(fù)審。當(dāng)然根據(jù)我們下文中討論的組織風(fēng)格，也可以讓有經(jīng)驗(yàn)的程序員對沒有經(jīng)驗(yàn)的程序員進(jìn)行指導(dǎo)。復(fù)審結(jié)對對軟件過程的最大意義就在于它形成了一個(gè)持續(xù)復(fù)審的體制，它保留了復(fù)審制度的優(yōu)點(diǎn)，而且可以克服復(fù)審制度中的缺點(diǎn)。例如花費(fèi)時(shí)間長，遭至開發(fā)人員的反感，不能夠進(jìn)行徹底的復(fù)審等等。

這三種方式的結(jié)對可以單獨(dú)實(shí)行，也可以配合實(shí)行。這三種方式雖然都不是完整的結(jié)對編程實(shí)踐，但是盡可能的獲得了結(jié)對編程好處，而成本是相對低廉的。剛開始實(shí)施結(jié)對編程或是沒有足夠的資源采用結(jié)對編程的，可以采用以上的變通方式。

結(jié)對編程的組織風(fēng)格

結(jié)對編程并不是抓鬮。成員的組織是需要一定的技巧的。基本的操作思路是，先找出溝通的關(guān)鍵性問題，然后針對問題入手，組織人員。舉一個(gè)例子來說，對于某個(gè)項(xiàng)目而言，參與的開發(fā)人員經(jīng)驗(yàn)較少，開發(fā)人員對組織的開發(fā)模式不熟悉，對開發(fā)的目標(biāo)領(lǐng)域也同樣不熟悉。主要的工作任務(wù)都壓到了經(jīng)驗(yàn)豐富的高級程序員身上。為了解決這個(gè)問題，在項(xiàng)目的頭幾次的迭代中，強(qiáng)制實(shí)行了配對制度，配對的基本思路是老手帶新手，配對的實(shí)現(xiàn)是老手編寫單元測試，要求新手實(shí)現(xiàn)，并共同進(jìn)行代碼復(fù)審（即采用測試結(jié)對和復(fù)審結(jié)對兩種方式）。在完成一個(gè)小模塊之后，老手就需要更換他的搭檔，以保證在前兩個(gè)迭代完成的時(shí)候，新手能夠較為獨(dú)立的進(jìn)行開發(fā)工作。一開始的進(jìn)度非常的不理想。老手也有著不同程度的怨言，認(rèn)為這是在耽誤時(shí)間。但高層管理人員聽取了項(xiàng)目負(fù)責(zé)人的匯報(bào)之后，表示支持這種做法。在所有的新手都和老手搭配過后，情況有了很大的變化。系統(tǒng)的開發(fā)速度明顯加快，團(tuán)隊(duì)內(nèi)已經(jīng)形成了密切溝通的氛圍，老手們能夠騰出手進(jìn)行更復(fù)雜的設(shè)計(jì)和質(zhì)量控制，更令人驚喜的是，已經(jīng)有兩名新手快要接近老手的水平了，這意味著，下一輪的結(jié)對編程過程中，他們將扮演當(dāng)老手的角色。

這個(gè)例子告訴我們：

• 針對重要的溝通問題實(shí)行結(jié)對編程
• 一次解決一個(gè)問題
• 結(jié)對編程的形式是針對溝通問題和環(huán)境特點(diǎn)而設(shè)計(jì)的
• 優(yōu)秀的實(shí)踐必須堅(jiān)持才能夠有效果

這是一個(gè)非常典型的組織風(fēng)格，可以適用于很多的軟件項(xiàng)目。它充分體現(xiàn)了溝通的重要性。更多的組織風(fēng)格還包括：

• 培訓(xùn)性項(xiàng)目。有時(shí)候這種項(xiàng)目也被稱為摸索性項(xiàng)目，項(xiàng)目的最大目標(biāo)就是為了研究和試驗(yàn)?zāi)承┘夹g(shù)，以便在軟件組織內(nèi)部推廣該技術(shù)。在這種項(xiàng)目中，知識的探索和研究往往要比成本更重要，因此可以采用結(jié)對編程的形式。
• 質(zhì)量控制。軟件開發(fā)的過程中，往往會(huì)有設(shè)計(jì)的核心部分。這部分的設(shè)計(jì)要么關(guān)系到軟件的整體結(jié)構(gòu)，要么就是代表了客戶最為關(guān)心的需求。這部分的軟件設(shè)計(jì)的好壞，將會(huì)直接影響客戶對軟件的看法。因此這部分的設(shè)計(jì)是值得投入雙倍的開發(fā)力量的。而在很多的項(xiàng)目中，我們發(fā)現(xiàn)很多開發(fā)人員并沒有意識到這一點(diǎn)，對開發(fā)人員來說，可能只是一些微不足道的錯(cuò)誤，但這些錯(cuò)誤有時(shí)候就會(huì)讓客戶留下非常不好的影響。因此，識別軟件中的重要部分并投入更多的開發(fā)力量，往往能夠令最終的軟件質(zhì)量有很大的提升。
• 輪崗制度。研究表明，即便是知識管理做的再好的組織，仍然是有大量的知識是保存在人腦中的。而為了不形成一個(gè)個(gè)的信息孤島，最好的信息流轉(zhuǎn)的方式就是溝通。輪崗制度，或者說是Cross Training，正是為了解決這一問題而設(shè)計(jì)的。輪崗制度解決的另一個(gè)問題是，保證你的團(tuán)隊(duì)中既沒有忙的團(tuán)團(tuán)轉(zhuǎn)的人，也沒有閑的發(fā)慌的人。這是管理著重要解決的問題，而輪崗制度可以很好的解決它。