就如同沒有3D游戲,，太平洋土著詞匯Voodoo也不會被人熟知一樣，原自夏威夷語wee kee wee kee的縮減化英語wiki,，如果沒有沃德·坎寧安(Ward Cunningham)1995年的突發(fā)奇想,，也不會被人為的創(chuàng)造出來。wee kee wee kee的原意是“快點,，快點”,，在1995年沃德·坎寧安(Ward Cunningham)為了方便社區(qū)群落方式的內(nèi)部交流，開發(fā)了一套名為波特蘭模式知識庫(Portland Pattern Repository)的工具,，在建立這個系統(tǒng)的過程中,，沃德·坎寧安突發(fā)奇想的創(chuàng)造了wiki技術(shù)。當(dāng)wiki在2003年8月傳入國內(nèi)時,，wiki被習(xí)慣性的譯成了維客,。

    “木子美讓博客概念在國內(nèi)一夜走紅，而維客很有可能是第二個博客”,，獨立網(wǎng)絡(luò)開發(fā)者李安科喃喃道,。實際上維客并不是一套復(fù)雜的系統(tǒng)，它與博客在思路上大有殊途同歸的意味,。博客完全是個人式的文字收集,，博客的閱讀者仍舊是被動的接收信息，如果對博客主人的某個觀點不滿,，最多也只能在文后附上幾句話抵觸的評論,，而在維客中，每個人既是閱讀者,，同時又是書寫者,。從技術(shù)角度上看維客不過是一套可以任意編輯的網(wǎng)絡(luò)白紙，任何人都可以在一段別人寫過的內(nèi)容上編輯加工,，也能夠按照一定技術(shù)規(guī)則和文化脈絡(luò)組合模仿?！渡虡I(yè)2.0》將維客形容為社群協(xié)作式寫作,，在他們看來維客必將是群體性知識總結(jié)歸納的最優(yōu)化模式,。臺灣地區(qū)維客組織管理員凌信路接受采訪時介紹說：“在維客上任何人都可以自由編輯別人的東西，自由開放的氣氛保持的很好,，所有那些喜好搞惡作劇在維客上都很規(guī)矩,，他們生怕任何言辭冒犯了維客群體的開放共享氛圍”。所以在維客上你見不到刺刀見紅的爭論,，也見不到任何網(wǎng)絡(luò)世界常見的爾虞我詐,。

    “維客簡直是天然的百科全書模式”，日本維客齡木久色在接受NHK采訪時說,。實際上仿照國外Wikipedia的中文維客百科剛剛開張,，整個維客百科系統(tǒng)完全就是一套百科全書的架構(gòu)，任何人都可以對自己了解和感興趣的領(lǐng)域開新百科分支,，并且把自己收集的資料書寫上去,。維客李安科說道：“我作為骨灰級玩家在中文維客百科上添加了電子游戲的部分，并且書寫了不少的內(nèi)容,，但卻陰錯陽差把名稱對應(yīng)錯了,，兩天后后悔不迭去修正時，卻發(fā)現(xiàn)已經(jīng)被別人修改過了,。”而在維客百科上,，對于“導(dǎo)演”一詞的解釋就前前后后被改了多次，最初的維客還按照《中國大百科全書》的說法：“把文學(xué)劇本搬上銀幕使其成為影片的主要藝術(shù)家”,，但是沒過幾天,，導(dǎo)演的解釋就被改成了“導(dǎo)演都是大流氓”。這就是維客的本色,，是一個共同創(chuàng)作各抒己見的社區(qū),，在維客的技術(shù)架構(gòu)里面并沒有等級分明的權(quán)限設(shè)置，不會讓你注冊然后輸用戶名和密碼,，也不會記錄你的IP,。因為維客們都信奉沒有鎖的門是最不怕被撬的門，這句英國古代諺語,。

    正是因為維客能夠堅持自由,、共享、信任和免費的原始精神信條,，從2001年開始,，英文維客百科已經(jīng)有了超過18萬個詞條，維客借助普通民眾的力量,，還在不斷的擴增,，信息詞條越來越接近6張CD容量的微軟電子百科全書了。而且維客對于新興詞語的反應(yīng)速度也很快,，正如楊百翰大學(xué)語言學(xué)教授賽弗·恰克在接受《商業(yè)2.0》采訪時說的,，“維客對于語言詞匯的積累是空前的,，被維客們歸納的知識在彼此間不停的共享”。除了在百科全書的成功之外,，維客技術(shù)也被引入到商業(yè)領(lǐng)域,，即將納斯達(dá)克上市，且預(yù)估市值高達(dá)400億美元Google內(nèi)部就是用維客系統(tǒng)溝通,，甚至摩托羅拉公司也把維客引入到公司內(nèi)部的知識管理中來,，《商業(yè)2.0》引述Google創(chuàng)始人拉里·佩奇的說法：“維客上涂涂改改的便捷非常適合現(xiàn)代管理制度下的職員交流，維客可以打破企業(yè)內(nèi)部各層隔閡,，讓那些靠壓制手段來管理的主管們被群體智慧淹沒”,。

對話專訪：聽Ward Cunningham細(xì)述Wiki之前世今生

記者/Bill Venners

在軟件社區(qū)中，Ward Cunningham享有思想源泉的美譽,。他發(fā)明了CRC Cards,，這是改進對象發(fā)現(xiàn)的一種技術(shù)。為了促進軟件模式的發(fā)現(xiàn)和編檔,，他發(fā)明了世界上第一個wiki,，一種基于web的協(xié)同編寫工具。最近,，許多極限編程（Extreme Programming）技術(shù)背后的主要靈感也被歸功于Cunningham,。

在2003年9月23日于丹麥Aarhus召開的JDOO大會上，Bill Venners遇到了Ward Cunningham,。在這次訪談中,，Cunningham深刻剖析了使用wiki協(xié)同探索和極限編程的幾個方面。

在第I部分“使用Wiki探索”中,，Cunningham討論了使用wiki協(xié)同探索以及wiki作者和讀者之間的權(quán)衡,。

在第II部分，Cunningham討論了他如何把wiki設(shè)計成這樣一種模型：集體代碼所有權(quán),、以所有權(quán)而自豪的集體激勵以及通過消除犯錯的代價來解決紛爭,。

在第III部分中，Cunningham討論了變更成本曲線的扁平化,、預(yù)測未來的問題以及像藝術(shù)家手中的泥巴那樣塑造程序,。

第I部分       使用Wiki進行探索

為什么需要Wiki？

Bill Venners：您發(fā)明wiki的最初目的是什么,？

Ward Cunningham：我創(chuàng)建wiki要完成幾件事,。第一個wiki的初衷是要建立一種環(huán)境，我們能夠交流彼此的經(jīng)驗,，從而發(fā)現(xiàn)編程的模式語言,。我以前曾經(jīng)使用過HyperCard組，它基本上也是為了類似的目標(biāo)。我知道人們喜歡使用那種HyperCard組來閱讀和創(chuàng)作,，但它是單用戶的,。當(dāng)開始PLoP（編程模式語言）系列討論會的時候,，我們認(rèn)識到我們真正想要做的是開始編寫一部新的作品,，我認(rèn)為我需要使用HyperCard組，并希望能找到一種應(yīng)用于web的等價物,。

對于wiki,，我還有更多通用的目標(biāo)。首先,，人們常說“人人喜歡講話”,，我認(rèn)為這里面有一種令人信服的人類本性。在創(chuàng)建wiki時,，我希望激發(fā)每個人喜歡講故事的天性,。其次，也許是最重要的一點,，我希望不經(jīng)常創(chuàng)作的人們會發(fā)現(xiàn)創(chuàng)作非常輕松,，這樣就有機會發(fā)現(xiàn)創(chuàng)作的結(jié)構(gòu)和方法。

Bill Venners：wiki如何使創(chuàng)作變得輕松,？

Ward Cunningham：不熟悉寫作的某個人可能有一個想法,，這個想法值得寫成一段。他們本來可以為雜志寫一篇評論,，但是一段文字太短了,。為了給雜志撰寫文章，他們不得不介紹一下背景,，講述某些重要的東西,，而且要以多數(shù)人都能理解的方式講述，然后結(jié)束文章,。太復(fù)雜了,，多數(shù)人都不愿意花費那么多的精力。

但是如果您正在閱讀別人的作品,，并想到“是的,，但是還有一點”可以放在一段中這樣說，“啊,，不錯,，但實際上還有……”在wiki上有很多這種類似于“對，但是……”的對比想法,。討論組也作了同樣的事情,，但是在討論組中這些對比都丟失了。

Bill Venners：為何在討論組中丟失了？

Ward Cunningham：因為沒有上下文,，無法持續(xù)下去,。討論組往往反復(fù)圍繞著同一個話題，但是人們忘記了以前說過什么,。我認(rèn)為,，常見問題解答（FAQ）的發(fā)明就是針對這個問題的。很多時候,，讀一讀FAQ要比參加討論組更有意義,。在一開始做wiki的時候，有一個系統(tǒng)叫FAQ-O-Matic,，它和wiki的想法一樣,，只不過其真正的目的是制作FAQ。我看到它的時候就想“哦,，英雄所見略同”,。不過我接下來又想，“不,，我更喜歡面向文檔的形式而不是問答形式,。”在我們的作品中想要創(chuàng)建的模式是某種類似FAQ的東西，但應(yīng)該不止如此?，F(xiàn)在,，wiki上可能有10,000到15,000種模式，25,000頁文檔,。

Bill Venners：您認(rèn)為wiki適合做什么,？wiki的高明之處在哪里？

Ward Cunningham：如果您試圖回答一個不容易闡述的問題,，事先不了解某種應(yīng)該知道的自然結(jié)構(gòu),，wiki會非常有用。對于像“項目進展如何”之類的問題,，我們可以設(shè)計一個數(shù)據(jù)庫,。但是數(shù)據(jù)庫中要放哪些字段還要歸結(jié)到對項目進展問題什么是重要的。關(guān)于項目的哪方面重要這些資料是不可預(yù)見的,。

Wiki頁面的格式非常自由,。在整個wiki中有一個超文本結(jié)構(gòu)，但是在一個給定的頁面上,，在自然語言靈活性的許可范圍之內(nèi),，您可以講任何想要述說的東西。因此,，wiki是跟蹤項目進展?fàn)顟B(tài)的一種良好方式,。比方說，您可以把我的模式作品看成是一個長期進行的項目。我們不知道終點在那里,，但是我們希望在進展中發(fā)現(xiàn)它,。

此外，wiki也非常適合于想要把控制權(quán)交給系統(tǒng)用戶的環(huán)境,。在wiki中并沒有多少何人何時可以做何事的邏輯,，因為wiki并不真正理解您在做什么。它只是為您保留頁面,。關(guān)于什么是適當(dāng)?shù)挠梅ㄊ裁词遣缓玫挠梅?，已?jīng)建立了大量的慣例,，但這些都存在于用戶的頭腦中,，而不是在應(yīng)用程序的業(yè)務(wù)邏輯中。如果您有一個可靠的團體,，不謀求通過計算機強制某種行為,，wiki就可以很好地工作。比如,，有人曾經(jīng)問我wiki是否適用于協(xié)同環(huán)境,。我認(rèn)為某些公司對它們的雇員完全具備這種信賴，某些公司則沒有,。不信賴雇員的公司可以根據(jù)某些需要維護一個web站點而不是wiki,。

把握大局

Bill Venners：讀者如何把握wiki上的總體內(nèi)容？

Ward Cunningham：首先要理解,，因為我們使wiki更方便作者,，實際上就增加了讀者使用的難度。里邊有某種組織方式,，這種組織方式還可以改進,，但它不是組織嚴(yán)密的。因此讀者就會感到仿佛是在茫茫的一片信息片段中搜尋,。偶然發(fā)現(xiàn)一段很好的信息,，于是就想，“好極了,，為什么沒有人哪怕只是把那些好的片段作一個清單,，我就不用再搜索其他的部分了。”換句話說,，“為何沒有人組織一下,，讓我迅速找到問題的答案？”早晚他們的想法會得到實現(xiàn),，“哎呀,，行了！”他們花了一個月或者兩個月查找所關(guān)心的東西，然后做一個頁面,，wiki組織成什么樣子由他們自己承擔(dān),。

我不是一個分類的癡迷者。如果感興趣的事物不符合需求或者不是預(yù)期的,，定義一個有用的分類方案非常困難,。不過有些人認(rèn)為每個頁面都應(yīng)該帶有分類。他們帶著一個分類方案,，根據(jù)頁面的名稱,，為wiki建立分類結(jié)構(gòu)。這些注重分類的人負(fù)責(zé)維護它,。如果某人創(chuàng)作了一個不能歸類的頁面,，其他的人就會說，“哦,，這應(yīng)該歸為wiki保留頁面或者設(shè)計模式,。”

Bill Venners：如何把一個頁面歸類為wiki保留頁？

Ward Cunningham：只需對一個叫做WikiMaintenanceCategory的頁面進行引用,。單擊該鏈接時,，就會轉(zhuǎn)到那一頁，對這種分類進行解釋以及為何有這一類,。因此把頁面歸到某一類,，習(xí)慣上是增加到該類別描述頁的鏈接。這樣標(biāo)記了該頁,。如果要了解這一類是什么,，可以沿著鏈接到類別描述頁。如果要看看這一類中有什么頁面,，可以搜索引用該類別頁的所有頁面,。

Bill Venners：我猜想搜索也許是研究新wiki的一種方式。從一定意義上講,，wiki類似于一種小型的internet,。 一切都分散在各處。如何發(fā)現(xiàn)正在尋找的內(nèi)容呢,？我可以從搜索關(guān)鍵字開始,。

Ward Cunningham：是的。任何名稱以“Category”結(jié)尾的wiki頁都是一個值得搜索的條目,?？梢酝ㄟ^Google搜索小說，但是如果有人不把作品標(biāo)記為小說,，就找不到它,。分類系統(tǒng)是一組頁面,，解釋分類的基本原理，可以讀讀這些頁面,。它們使用了名稱空間的一小部分——所有這些詞都以“Category”結(jié)束——并建立了這些頁面涉及其他頁面分類的實例,。非常棒。還在發(fā)展中,。如果我要做一個解決方案,，可能會非常簡單，甚至同樣好,。我最喜歡的一點是,，有一個非常積極的社區(qū)在管理這些分類。有時他們把分類搞錯了,，但很快就會糾正過來,。

Wiki中的時間要素

Bill Venners：您所說的有點讓我想起“自由討論”。您把一些人集合起來充實那些您還不完全清楚的事物,。

Ward Cunningham：Wiki有點像“自由討論”,，盡管不是交互式的。您可以做10分鐘的自由討論,，用30分鐘分析自由討論的成果，然后在45分鐘之內(nèi)完成某件事,。Wiki的腳步要慢一些,。您可以就某個觀點寫一個頁面，或者就很多想法寫一個頁面,。然后在一周之內(nèi)回來看看頁面上有什么進展,。但是如果在15分鐘之內(nèi)回來，不會發(fā)生太多的變化,。Wiki上的事情是以天或者周為周期的,，因為人們往往每天或每周瀏覽一次。

Wiki中有一個有趣的時間特性,。讀新聞組或者郵件列表時,，會有一種感覺，當(dāng)前就是您在列表中的位置,。我不希望wiki中有一個時間表,。當(dāng)在讀wiki上的某些內(nèi)容時，我不希望時間會影響您,，不論它是一年前寫的還是一天或者一分鐘前寫的,。這意味著我們需要通過某種方式得到上下文。

如果您正在編寫一個頁面,，那個頁面必然和其他某個頁面有關(guān),。因此所要做的就是,，在一個段落中說明其他頁面中哪一些是關(guān)于這個上下文的。人們逐漸熟悉這些頁面的名稱,。他們遇到一個新的頁面,，閱讀包含對上下文頁面鏈接的段落。如果已經(jīng)度過這些頁,，就繼續(xù)讀下去,。如果不知道這些頁，他們就會說,，“哦,，這一頁沒有什么意思。我還得讀一讀其他的頁,。”這樣如果您了解上下文的話,，就不必再去看了。但是如果不了解上下文,，您可以去看一看,。上下文不會變。

Bill Venners：聽起來似乎您必須了解wiki站點,。過一段時間后您就會熟悉它了,。一開始可能會令人感到困惑，也沒有多少提示,，您進來發(fā)現(xiàn)到處都是這樣的內(nèi)容,，但不一定是根據(jù)讀者的需要組織的。

Ward Cunningham：對,，wiki總是在不斷地組織中,。每花費一個小時組織，都要花費另外兩個小時來增加新的材料,。因此wiki的總是處于半組織化狀態(tài),。

Wiki 和可讀性

Bill Venners：我確實非常喜歡wiki的思想，但是我發(fā)現(xiàn)閱讀許多wiki頁非常困難,?？勺x性的問題是我一直沒有在Artima.com上增加wiki的主要原因。Artima.com也是一種基于web的協(xié)作文檔,，但是更加結(jié)構(gòu)化,。在wiki中沒有專職編輯為讀者組織材料。所有的頁面都是協(xié)作性的,。結(jié)構(gòu)是協(xié)作性的,。編輯是協(xié)作性的。從wiki的協(xié)作性中有什么足以抵消可讀性的損失,？

Ward Cunningham：作為wiki讀者,，您能夠獲得以前沒有發(fā)言的那些人的觀點,。聽我們發(fā)言的人對于怎樣編寫和發(fā)布計算機程序有直覺的想法。我們這一行在發(fā)表過程中對傳統(tǒng)保留了某些尊重,。比如,，如果您想為一本科學(xué)雜志投稿，應(yīng)該經(jīng)過同行評審,。同行評審的一部分是你應(yīng)該熟悉所有其他作品,。而其他作品可能糾纏進某些細(xì)枝末節(jié)。關(guān)于編程的作品有時并不符合程序員的實際感觸,。有了wiki,，沒有時間學(xué)習(xí)寫作并在雜志上開辟專欄的實踐程序員，就有機會講出那些對于他們來說是重要的事情,。Wiki提供了一個不同的視角,。事實上，您可以分辨出一個人是在wiki上根據(jù)自己的經(jīng)驗創(chuàng)作,，還是轉(zhuǎn)述剛剛讀到的東西,。

Bill Venners：那么您怎么分辨呢？

Ward Cunningham：您可以根據(jù)他們談?wù)撌虑榈姆绞絹韰^(qū)分,，比如“Mary Ann就是做不好這一部分,。”這不符合科學(xué)傳統(tǒng)。如果有人引述某位作者的話,，“某某怎么說,，你這家伙怎么聽不明白”，有人在贊美他所讀的書,。另一方面，如果有人說,，“您知道,，在以前的三個項目中我們都嘗試過，但一次也沒成功,，我們只能用別的辦法擺平它,。”有個家伙解決了這個問題，他正在跟我談一些深刻的問題,。如何解釋要靠我自己,。這只是他的經(jīng)驗。然后您可能還會看到其他幾段文字,，“是的,，我也遇到過，我用這種方法搞定了,。”那么現(xiàn)在就有兩種方法了,。突然之間,，您開始與解決了軟件問題的人交流了，而不是和談?wù)摻鉀Q軟件問題的人交流,，這有很大的不同,。

第II部分            代碼和文本集體所有權(quán)

集體的代碼和文本

Bill Venners：極限編程（XP）的集體代碼所有權(quán)特點讓我想到了wiki，在wiki中,，每個人對所有一切負(fù)責(zé),。

Ward Cunningham：這樣做完全是有意的。在設(shè)計wiki前的幾個月中,，我們有過一次爭論,。我認(rèn)為Kent Beck和我站在一邊。堅信主流軟件工程教條的那些人站在另一邊,。我們說“集體代碼所有權(quán)很好,。”他們則說“太荒謬了。沒有職責(zé)劃分,，而沒有責(zé)任就決不會有質(zhì)量,。讓他們避免制造缺陷，就必須把缺陷和某個人掛鉤,。”我說,，“完全不對。”

我設(shè)計wiki的決定,，很大程度上受到建立一種協(xié)同過程模型的渴望所啟發(fā),，我認(rèn)為在大型代碼庫中應(yīng)該有這種協(xié)作。我希望wiki能夠模擬這種情況,。比方說在一堆代碼中有一個問題,。您知道怎么解決問題，但是解決需要涉及到大量模塊,。重構(gòu)需要大量艱苦的工作,，如果要同每個最初的作者協(xié)商就更加困難。你只是希望改正問題,。

困難在于代碼可能是按層次結(jié)構(gòu)組織的,，但是解決方案可以從多方面來考慮，而不止是某種層次結(jié)構(gòu),。因此當(dāng)您在某一方面發(fā)現(xiàn)一種貫穿整個層次結(jié)構(gòu)的解決辦法時,，您只能隨著解決方案的要求，在適當(dāng)?shù)牡胤郊尤虢鉀Q方案,。我們經(jīng)常發(fā)現(xiàn)自己處于這樣一種境地,，人們了解這個程序，但是他們不能將這些知識應(yīng)用于程序,。為什么,？因為知識的發(fā)展和在擁有這些知識之前做出的某些組織決策相沖突,。換句話說，程序抗拒知識的積累,。

Bill Venners：抗拒,？

Ward Cunningham：程序?qū)δ撤N類型的知識有抵抗力——沒有預(yù)計到的知識——因為很難在一開始就設(shè)立的結(jié)構(gòu)內(nèi)表達(dá)這些知識。很難把不符合這種結(jié)構(gòu)的任何東西加進去,。

Wiki中也有一點對預(yù)料之外思想的抗拒,，但這種抗拒主要在人們的實踐中。Wiki中寫進去的東西越多,，對自身權(quán)利的要求越嚴(yán)格,，但是如果有人要修改而且到第25頁去修改，他們就可以去25頁,。

比如,，在wiki中，發(fā)生的某個過程是頁面從討論發(fā)展成短文,。許多人愿意閱讀討論,。那些每天訪問wiki的人希望看看昨天又說了什么，因此需要按時間組織的頁面,。但是對學(xué)習(xí)而言,，投稿先后順序并不是一種很好的組織原則。因此頁面總是保持某種討論之中的感覺,，直到這個討論結(jié)束,。后來，有人又回來閱讀了這些討論,，把您可能稱之為線性模式的頁面重新組織成文檔模式的頁面,。

如果在注解之間轉(zhuǎn)來轉(zhuǎn)去，而且有許多類似的彼此相鄰的注解,，您經(jīng)常會發(fā)現(xiàn)可以去掉一大半篇幅,。因為只要位置適當(dāng)，一句話可能就說明白了,。在Ward的wiki上，這個過程被稱為“重構(gòu)（refactoring）”,，就像我們在軟件中那樣稱呼這個過程,。Ward的wiki是關(guān)于軟件的，其中有許多從事軟件的人,，因此稱為重構(gòu),。在其他地方可能就會稱為“編輯”了。在Ward的wiki上,，重構(gòu)是一個持續(xù)的過程,。設(shè)想如果某些地方被證明不很合適,，就要再次進行重構(gòu)。一切都是重構(gòu)的目標(biāo),。這也是我們愿意在軟件中所看到的,。

軟件的優(yōu)勢是它有明確的解釋。因為軟件是為機器編寫的,，我們可以依靠精確的解釋編寫測試,。在重構(gòu)程序時，我們可以測試沒有破壞或者丟失的任何東西,。但wiki是為人類編寫的,，沒有精確的解釋。我可以說,，“哎呀,，我可以把這個句子放在這兒，并砍掉一半,，因為在這個上下文中很容易理解,。”但是我可能錯了。對于我容易理解,，但可能對其他人很難,，我也沒法做測試。因此在重構(gòu)過程中,，我們可能會丟失wiki上的某些信息,。Wiki像一個信息漏桶。它每天都在丟失信息,。但是有更多的信息加進來,，因此凈結(jié)果是正的。即使丟失了某些東西,，wiki總是比昨天有更多的內(nèi)容,。

高質(zhì)量代碼的集體激勵

Bill Venners：從您的描述中我了解了集體代碼所有權(quán)的好處。但代價是什么,？集體代碼所有權(quán)的缺陷是什么,？

Ward Cunningham：我相信有一些缺陷，但是現(xiàn)在還沒有想到,。

Bill Venners：所有權(quán)的自豪感又如何,？人類適應(yīng)集體自豪感嗎？在您自己創(chuàng)建什么時,，總是希望把它做好,。

Ward Cunningham：我認(rèn)為集體所有權(quán)實際上更好一些。是的，我對自己所做的事情感到自豪,。對于我而言,，自豪感是一種激勵。通過集體所有權(quán),，我們基本上建立了一種小型的社區(qū),，訓(xùn)練他們自我肯定所做的工作。但如果歸我所有,，人們就會說,，“那是Ward的模塊，我不想看Ward的模塊,。”如果必須調(diào)用Ward的模塊,，他們可能會喜歡該模塊的API。我的模塊缺陷率很低也許會給他們留下印象,。不過他們可能會說,，“他的模塊很簡單。他有一個容易編寫的模塊,，這就是為何他的缺陷率這么低,。”他們不會知道真正的原因。

當(dāng)人們使用我提供的材料時,，他們會感覺到是否容易使用,。所謂使用材料，我是指拿來代碼調(diào)整,，以便做更多一點工作或者稍微改變其功能——這些代碼應(yīng)該做的任何事情,。當(dāng)人們使用代碼時，他們會看到我努力完成的一些事情,，否則的話他們永遠(yuǎn)也不會注意到,。不需要迫使他們說“Ward你很了不起”，但有時候他們會說,，“Ward你很了不起,。”這就滿足了我的自負(fù)感。所有權(quán)的自豪感,？的確如此,。

現(xiàn)在，不需要在每一行上寫上我的名字,。事實上,，這證明如果它確實很好，可能是因為他們做得好,，而不是我。我可能只是做了一個計劃，然后他們完成了而且完成得很好,。我可能會受到不應(yīng)得到的榮譽,，不過他們也可能把贊譽送給別人。一個想法來自誰,，榮譽應(yīng)歸誰,，這種觀點是彈性的。但我認(rèn)為人們在知道誰參與其中的時候,，可以很好地解決這種彈性,，承認(rèn)每個人的貢獻。通過集體所有權(quán),，我們建立了一種社會環(huán)境,，通過源代碼語句中迸發(fā)的智慧可以了解一個人。

Bill Venners：集體所有代碼的這種特點為何不能出現(xiàn)在wiki頁面上,，wiki頁面上的內(nèi)容有時候顯得有點亂,？

Ward Cunningham：我肯定也會這樣。

Bill Venners：您剛才談到某一行代碼是誰編寫的并不總是很明顯,。對于wiki頁面也是如此,。誰寫了某一行文本也并不總是很明顯的。有時候一個人在wiki頁面上寫了一些東西,，“我有這樣的經(jīng)驗”,，而作為讀者我并不知道這個“我”到底是誰。集體代碼所有權(quán)和集體文本所有權(quán)相比有什么不同,，您剛才只談到了代碼而沒有涉及文本,？

Ward Cunningham：我認(rèn)為不可預(yù)料的代碼是很常見的。代碼可能能夠工作,，但如何工作本質(zhì)上是秘密的,，不可能閱讀。事實上,，這也可能是一種常見情況,。因此混亂可能不夠確切，應(yīng)該是不可讀,。我有與他人長期結(jié)對編程的經(jīng)驗,，在讀到他們的代碼時，甚至認(rèn)為是自己的代碼,。但在wiki上還沒有出現(xiàn)這種情況,，我讀到某人的文字而認(rèn)為是自己寫的。這可能是因為代碼具有更高的組織性,，但我認(rèn)為更可能是因為代碼交流的范圍更狹窄,。代碼交流的范圍僅限于某種過程的計算機化，而談話的最佳方式是相當(dāng)廣泛的。這樣就會導(dǎo)致和英語相比,，代碼會更快地具有穩(wěn)定的組織性,。

解決紛爭

Bill Venners：在“Extreme Programming Explained”一書中， Kent Beck寫道,，“集體所有權(quán)增強了在項目中對個人能力的認(rèn)知,。您不會永遠(yuǎn)釘住別人的蠢事不放。您在途中發(fā)現(xiàn)了某些東西,，然后把它排除掉,。”對于什么是蠢事如果不同人的看法互相矛盾時該怎么辦？所謂蠢事不是一種主觀的評價嗎,？

Ward Cunningham：啊,，我決不會這樣說。當(dāng)我認(rèn)識到不需要贏得每一次爭論的時候,，這是我編程生涯中的一個轉(zhuǎn)折點,。我正在和別人討論代碼，我說“我認(rèn)為最好的做法是A”,，他們則說“我認(rèn)為最好用B”,。我說“不，應(yīng)該是A”,，他們則堅持說“我們想用B”,。當(dāng)我能夠這樣回答的時候，對我而言這是一個轉(zhuǎn)折點：“好吧,，用B辦法,。如果我錯了這樣就不會損害我們。如果我對了,，而您用B辦法也不會造成多少損害,，因為我們可以改正錯誤。讓我們看看這樣做是否錯了,。”

我們不要把自己看成非常幸運的預(yù)言者,，要求自己預(yù)測未來。最好是建立一種環(huán)境,，這樣您就能夠試一試B并看看發(fā)生什么?，F(xiàn)在證明爭吵通常是無益的。無論誰編程,，都可以自由選擇編程的方式,，這樣就足夠了。當(dāng)然有時候也可能會證明爭論是有用的,。我們正在做別的事情,，看了看說,，“您知道，用在那里并不合適,，因為B確實不符合,。”而這個問題可能是我在宣傳A方法時正好考慮到的，也可能不是,。它可能是開發(fā)人員在方法B的上下文中硬塞進去的。但有時候您了解這些缺陷或者難以改進的地方,。于是開發(fā)人員說,，“你知道，這些代碼令我感覺不舒服,。”我說“好吧,，我可以解決這個問題”。他們問道“您行嗎,？”我說,，“當(dāng)然，我可以解決這個問題,。您做了B,，我就使用B。”然后我就可以開始處理它,，只要可能就盡量使用B,。但是因為承擔(dān)了職責(zé)，我就有機會使它實現(xiàn)需要的功能,。

Bill Venners：您是說再回到A,。

Ward Cunningham：如果需要的話。

Bill Venners：也可能是到C,。

Ward Cunningham：通常會變成C,。對于我們雙方這都是一種學(xué)習(xí)的經(jīng)歷。如果沒有這種經(jīng)歷,，我們就都沒有學(xué)到什么,。Ward贏了，其他人輸了,?；蛘呦喾础＿@和一場戰(zhàn)爭差不多,。為什么不說,，“好吧，讓我們編碼看看怎么樣,。如果不行的話我們再改變,。”

我無法告訴你我花費了多少時間擔(dān)心無關(guān)緊要的決策,。如果能夠做一項決策，然后看看結(jié)果如何,，當(dāng)然會大大減少這種擔(dān)憂,，但是這意味著您必須建立一種環(huán)境，當(dāng)確實出問題時可以修正,。如果某些事情確實出了問題,，不會浪費您和您的客戶過多的成本。這不是一種可笑的花費,。如果您處于不能承受錯誤的情況下,，就很難做正確的事情。因此如果嘗試做正確的事情,，正確的事情可以抵消犯錯誤所造成的代價,，要遠(yuǎn)比猜測什么是正確的好。

比如,，在一個項目中我們通過經(jīng)常升級抵消了錯誤成本,。我們是通過建立一個相當(dāng)精細(xì)的數(shù)據(jù)庫模式演化機制實現(xiàn)的。,。我們曾經(jīng)每周發(fā)布一次,，每周都修改模式。我們可以為不同的客戶根據(jù)不同的要求對模式作不同的修改,，把這一切結(jié)合起來最終得到正確的結(jié)果,。因為我們每周都在做，大約六周或八周以后,，我們就確信我們可以完成它了,。我們從沒有擔(dān)心過。多數(shù)人都說,，“無論做什么,，千萬不要做模式演化除非你已經(jīng)做了。”但在項目結(jié)束的時候,，他們說,，“天哪，我們真的做到了,。”因此在從來沒有做過之前,，他們說，“只要我們?nèi)プ?，就讓我們做完它吧?#8221;他們做了一個巨型項目,，以前從未有這樣的經(jīng)驗。你猜怎么樣,？他們錯了,。相反,，我們每周都在做。每周做一點,。我們確實從中受益了,。我們永遠(yuǎn)不會害怕它。它也從來沒有出現(xiàn)問題,。

因此我們不是通過說“我們要做的工作性質(zhì)就是這樣”,，從而通過抹去問題來解決問題。要是這么簡單的話才是真的奇怪了,。實際上更多的是提問的方法,，“您希望擅長什么？”,，如果您希望擅長它，就找出一種方法來每天應(yīng)用它,。如果每天都要應(yīng)用,，那么就只能熟練掌握了。因此,，選擇您希望擅長什么,。您應(yīng)該擅長您所害怕的東西，這樣您就不會再害怕它了,。

第III部分      塑造程序

變更的成本

Bill Venners：在“Extreme Programming Explained”一書中,，Kent Beck寫道，“軟件工程中一個普遍的假設(shè)是程序修改的成本隨著時間呈指數(shù)級增長,。”并建議說,，“通過技術(shù)和編程實踐的結(jié)合，有可能得到一條方向相反的曲線,。”怎么能夠?qū)崿F(xiàn)變更成本曲線的扁平化呢,？

Ward Cunningham：傳統(tǒng)上來說，變更成本曲線告訴我們,，早發(fā)現(xiàn)變更的需要與晚發(fā)現(xiàn)這種需要相比,，進行變更所花費的代價越小。我批判了這種曲線,，因為根據(jù)這種理論,，我們差不多可以故意犯錯，然后在實踐中改正錯誤,，這樣有助于減少以后變更的成本,。

我們認(rèn)為，任何變更的決定因素不是何時進行變更,，而是需要做多少思考,。如果我們每周做一次變更,，而理解我們的真正需要花費了兩天，那么做這種變更就需要兩天,。如果我們每21周變更一次,，理解我們的真正需要也花費兩天時間，那么這個變更也用了兩天,。

在每周一次的變更中,，我們可能要寫20條語句。在21周變更一次時,，我們可能需要寫20條語句并修改4條語句,。但是如果您習(xí)慣于變更，修改4條語句也花不了多少時間,。只需要找到那些語句并修改它,，可能只需要1分鐘。

因此理解變更的需要是決定性因素,。編程實現(xiàn)變更并不重要,。只要我們理解了變更，我們就可以編程實現(xiàn),，或早或遲,。修改代碼的實際成本并不在編程中占有主導(dǎo)地位。主要的成本是理解所花費的時間,，這就給出了一條趨向平緩的變更成本曲線,。

許多人害怕變更，是因為盡管在編寫的時候還理解代碼,，但這種理解很快就消失了,。他們對你說，“我們?yōu)檫@些語句費盡了心血,，無論如何不要改變這些語句,！”他們并不想回到原來的代碼，因為重新理解太費勁了,。因此使變更成本曲線扁平的另一種方法,，即以后變更的成本不會比現(xiàn)在更大，就是確定人們必須能夠看到他們將要改變什么并理解它,。因此,，當(dāng)你在編寫代碼時，你就會更多地為將要閱讀代碼的人編寫,，而不是為運行它的機器編寫,。

同樣，你也不愿意編寫大量的注釋,，告訴別人如何進行他們所需要的修改,，因為您并不知道他們要進行何種修改,。最好抱有這樣一種觀點，您不能幫助將來的程序員進行修改,。您所能做到的就是使他們?nèi)菀桌斫饽θプ龅氖?。如果您非常小心，避免做太多的事情,，這樣最有助于他們理解您的努力,。您試圖完成的功能越多，將來的程序員要理解您的代碼就越困難,。

比方說,，如果您明顯地忽略了一種情形，以后的程序員需要解決它,，他們打開代碼發(fā)現(xiàn)您顯然是忽略了這種情形,。這意味著他們可以自由實現(xiàn)需要的任何功能。但是如果您試圖應(yīng)付這種情形,，他們來了首先要確定哪里不工作,。他們將看到您試圖解決這種情況，因此他們首先要嘗試?yán)斫饽谧鍪裁?。一旦理解了您要做什么，他們就可以指出如何修改以實現(xiàn)需要的功能,。他們更愿意接手的時候發(fā)現(xiàn)您甚至沒有考慮到這一點,。也許您想到了，但完全沒有對此編程,。

對未來的預(yù)測

Bill Venners：每個人都同意預(yù)測未來是很困難的,，但預(yù)測總是這么糟嗎？

Ward Cunningham：在科學(xué)中預(yù)言未來很簡單,?？茖W(xué)建立在對物理系統(tǒng)行為研究的基礎(chǔ)上，被證明具有驚人的可預(yù)言性——可能天氣除外,。我們已經(jīng)能夠向太空發(fā)射火箭并使它沿軌道運行,，這是預(yù)測的一個范例。但是當(dāng)開始談及對未來的期望時,，我們可能有某些直覺,，這些直覺也許是對的，但不會總是對的,。我們必須考慮到不正確的情況,。

當(dāng)一個新的需求出現(xiàn)時，我們看了看說,，“好的,，這不難,。這個程序就是為它而作的。”我們在程序中加入一些代碼,，然后就成了——我喜歡這樣,。我討厭這種情況，新需求的出現(xiàn)不能很好地滿足,，仿佛程序的設(shè)計就是為了和需求作對,。這種情況下，我們有大量的工作要做,。但是這項工作的性質(zhì)要求首先修改程序使它更容易適應(yīng)新的需求,，然后把新的需求包含進來就很容易了。換句話說,，不是為新的需求在并不適合這種需求的結(jié)構(gòu)上打補丁,，而是全力以赴做艱難的任務(wù)修改結(jié)構(gòu)，使它能夠很容易實現(xiàn)這種需求,。打補丁的辦法意味著,，后來者不但要理解并非為這種需求設(shè)計的系統(tǒng)，還要理解試圖彌補但不改變系統(tǒng)的那些補丁,。最好是修改系統(tǒng)以便很容易適應(yīng)新的特性,。

有人也許會說，“為什么不向前看一看,，了解我們必須做到的所有工作呢,？為什么不從一開始就把系統(tǒng)設(shè)計成使所有工作更方便呢？”如果您能夠?qū)崿F(xiàn)這樣一個系統(tǒng),，那真是太好了,。正是這樣，人們一次又一次地試圖設(shè)計系統(tǒng)使明天的工作更容易,。但是當(dāng)明天到來時,，卻發(fā)現(xiàn)他們并沒有很好地理解明天的工作，實際上他們使明天的工作更難了,。

意外的體系結(jié)構(gòu)

Bill Venners：為了批駁變更成本曲線,，您發(fā)現(xiàn)了一種方法可以在項目的整個生命期中進行變更。這就使得對將來的計劃不那么重要了,，因為可以在以后真正需要展開的時候進行變更,。整個體系結(jié)構(gòu)僅僅是在每次只關(guān)注一小步的過程中逐漸浮現(xiàn)出來的嗎？

Ward Cunningham：我喜歡塑造程序這種說法,，就象藝術(shù)家塑造一團泥巴一樣,。藝術(shù)家想做一個雕塑，但是在開始雕塑之前，她只是把泥巴揉來揉去,。她開始逐漸塑造成形,，并看到泥巴要成為什么樣子。揉捏得越多,，泥巴就越像她希望的樣子,，最終變得完全符合她的想法。

一個開發(fā)小組用了數(shù)月編寫一段代碼,。最初,，他們做了一段代碼，有點僵硬,。代碼很短,，但仍然有點僵硬。他們攪動這些代碼,，代碼稍微變軟了點,。在上面提到的一個項目[第II部分]中，我們向數(shù)據(jù)庫增加了模式演化功能,。它軟化了程序,，變更容易多了。每次變更模式時,，我們都作一點改進,。程序員和代碼——作為一個整體——都軟化了。我們塑造程序并保持它的柔軟性,。

在項目結(jié)束時您已經(jīng)完成了需要做的所有事情——有人為之付錢的所有功能——您看了看代碼問道,，“這一堆東西中的核心是什么呢？這是怎么完成的,？我們?nèi)諒?fù)一日地編寫程序，它是怎么結(jié)束的呢,？”通常程序的結(jié)束都是令人驚詫的,。您會說，“這是一種優(yōu)美的結(jié)構(gòu),。”那么體系結(jié)構(gòu)又從何而來呢,？

在這里，體系結(jié)構(gòu)意味著我們處理不同需求的系統(tǒng)化方式,。當(dāng)我們根據(jù)需要塑造程序時,，體系結(jié)構(gòu)使我們能夠發(fā)現(xiàn)進展到哪里了。融入程序的是一個系統(tǒng),，包括我們所做的每一個小決策——正確的小決策,，錯誤但改正了的小決策。從某種意義上講我們得到的這個體系結(jié)構(gòu)并沒有經(jīng)過嘗試。在其他決策上下文中的所有決策凝結(jié)成了一種體系結(jié)構(gòu),。