Ward Cunningham全名為 Howard G. Cunningham，中文譯名沃德·坎寧安（或沃德·坎寧漢）?，F(xiàn)居住于俄勒岡州的波特蘭。

　　沃德·坎寧安是一名著名的計算機(jī)程序員，模式研究和極限編程有較大影響?？矊幇矌缀跎娅C過所有的編程模式，包括面向?qū)ο蠛兔艚萁?。同時，他是wiki概念的發(fā)明者，并建立了第一個wiki網(wǎng)站波特蘭模式知識庫。

　　沃德·坎寧安從普度大學(xué)獲得（電子工程和計算機(jī)科學(xué)的）交叉學(xué)科工學(xué)學(xué)士學(xué)位以及計算機(jī)科學(xué)的碩士學(xué)位。

　　他1995年在波特蘭模式知識庫創(chuàng)建了第一個Wiki站點(diǎn)。這個站點(diǎn)現(xiàn)在還在運(yùn)作，致力于“人，項(xiàng)目和模式”，并且是一個“程序設(shè)計語言思想的非正式歷史”。例如，這個站點(diǎn)被用來為有用的軟件開放的模式語言以及極限編程的軟件方法的發(fā)展進(jìn)行分類?？矊幇蔡岬絎iki的概念是他在20世紀(jì)80年代末期想到的，并且他首先使用HyperCard堆棧的方法進(jìn)行實(shí)現(xiàn)。

　　他是《The Wiki Way》（2001年）這本書的作者（與Bo Leuf合著）。

　　他是Cunningham & Cunningham, Inc.公司的創(chuàng)始人。他還是Wyatt Software研發(fā)部門的總裁，以及Tektronix Computer Research Laboratory的主要工程師。沃德·坎寧安之所以聞名的是對面向?qū)ο蟪绦蛟O(shè)計的開發(fā)實(shí)踐的貢獻(xiàn)，這個變種叫做極限程序設(shè)計，以及由他的WikiWikiWeb提供的社團(tuán)。他還是“山坡組”的創(chuàng)始人，并且作為其贊助的“程序的模式語言”會議的程序主席。

　　2003年12月，沃德·坎寧安加入微軟，為微軟的“模式與實(shí)踐”組工作。從2005年10月開始他轉(zhuǎn)入Eclipse基金會。

　　坎寧安自陳wiki的想法源自1980年代後期，“我創(chuàng)建第一個Wiki的初衷就是要建立一種環(huán)境，我們能夠交流彼此的經(jīng)驗(yàn)?！?。并且他首先使用HyperCard（一個數(shù)據(jù)庫圖示軟件）堆棧的方法進(jìn)行了離線wiki的試驗(yàn)。

　　1995年，坎寧安在Purdue大學(xué)計算中心工作時，為了方便模式社群的交流建而建立了一個工具——波特蘭模式知識庫（Portland Pattern Repository）。在建立這個系統(tǒng)的過程中，沃德·坎寧安創(chuàng)造了wiki的概念和名稱，并且實(shí)現(xiàn)了支持這些概念的服務(wù)系統(tǒng)，這就是最早的wiki系統(tǒng)（建立時間：1995年3月25日）。

　　波特蘭模式知識庫現(xiàn)在還在運(yùn)作，致力于“人，項(xiàng)目和模式”，并且是一個“程序設(shè)計語言思想的非正式歷史”。例如，這個站點(diǎn)被用來為有用的軟件開放的模式語言以及極限編程的軟件方法的發(fā)展進(jìn)行分類。

　　從1996年至2000年間，波特蘭模式知識庫圍繞著面向社群的協(xié)作式寫作，不斷發(fā)展出一些支持這種寫作的輔助工具，從而使Wiki的概念不斷得到豐富和傳播，并在網(wǎng)絡(luò)空間出現(xiàn)了許多類似的網(wǎng)站和軟件系統(tǒng)，其中最有名的就是維基百科。

　　坎寧安曾列舉了若干wiki的設(shè)計原則，其中較為重要的如：開放（Open），當(dāng)網(wǎng)頁內(nèi)容不完整或未加以適當(dāng)組織時，所有人都可以以他們認(rèn)為適當(dāng)?shù)姆绞郊右跃庉?；遞增（Incremental），網(wǎng)頁可以引用其他網(wǎng)頁，甚至包括那些不存在的文件。普遍（Universal），編輯與組織文件的機(jī)制，應(yīng)該與書寫時相同，因此書寫者同時也可以是編輯、編纂者；明顯（Observable）表明了網(wǎng)站內(nèi)的行為必須受到該網(wǎng)站其他的瀏覽者檢閱；集中（Convergent）重復(fù)的內(nèi)容借由類似與相關(guān)內(nèi)容的引用後，可以進(jìn)行移除。

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

為什么需要Wiki？

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

　　Ward Cunningham：我創(chuàng)建wiki要完成幾件事。第一個wiki的初衷是要建立一種環(huán)境，我們能夠交流彼此的經(jīng)驗(yàn)，從而發(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ā)每個人喜歡講故事的天性。其次，也許是最重要的一點(diǎn)，我希望不經(jīng)常創(chuàng)作的人們會發(fā)現(xiàn)創(chuàng)作非常輕松，這樣就有機(jī)會發(fā)現(xiàn)創(chuàng)作的結(jié)構(gòu)和方法。

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

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

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

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

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

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

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

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

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

把握大局

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

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

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

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

　　Ward Cunningham：只需對一個叫做WikiMaintenanceCategory的頁面進(jìn)行引用。單擊該鏈接時，就會轉(zhuǎn)到那一頁，對這種分類進(jì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é)束——并建立了這些頁面涉及其他頁面分類的實(shí)例。非常棒。還在發(fā)展中。如果我要做一個解決方案，可能會非常簡單，甚至同樣好。我最喜歡的一點(diǎn)是，有一個非常積極的社區(qū)在管理這些分類。有時他們把分類搞錯了，但很快就會糾正過來。

Wiki中的時間要素

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

　　Ward Cunningham：Wiki有點(diǎn)像“自由討論”，盡管不是交互式的。您可以做10分鐘的自由討論，用30分鐘分析自由討論的成果，然后在45分鐘之內(nèi)完成某件事。Wiki的腳步要慢一些。您可以就某個觀點(diǎn)寫一個頁面，或者就很多想法寫一個頁面。然后在一周之內(nèi)回來看看頁面上有什么進(jìn)展。但是如果在15 分鐘之內(nèi)回來，不會發(fā)生太多的變化。Wiki上的事情是以天或者周為周期的，因?yàn)槿藗兺刻旎蛎恐転g覽一次。

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

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

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

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

Wiki 和可讀性

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

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

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

集體的代碼和文本

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

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

　　我設(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)用于程序。為什么？因?yàn)橹R的發(fā)展和在擁有這些知識之前做出的某些組織決策相沖突。換句話說，程序抗拒知識的積累。

　　Bill Venners：抗拒？

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

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

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

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

　　軟件的優(yōu)勢是它有明確的解釋。因?yàn)檐浖菫闄C(jī)器編寫的，我們可以依靠精確的解釋編寫測試。在重構(gòu)程序時，我們可以測試沒有破壞或者丟失的任何東西。但 wiki是為人類編寫的，沒有精確的解釋。我可以說，“哎呀，我可以把這個句子放在這兒，并砍掉一半，因?yàn)樵谶@個上下文中很容易理解。”但是我可能錯了。對于我容易理解，但可能對其他人很難，我也沒法做測試。因此在重構(gòu)過程中，我們可能會丟失wiki上的某些信息。Wiki像一個信息漏桶。它每天都在丟失信息。但是有更多的信息加進(jìn)來，因此凈結(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)實(shí)際上更好一些。是的，我對自己所做的事情感到自豪。對于我而言，自豪感是一種激勵。通過集體所有權(quán)，我們基本上建立了一種小型的社區(qū)，訓(xùn)練他們自我肯定所做的工作。但如果歸我所有，人們就會說，“那是Ward的模塊，我不想看Ward的模塊。”如果必須調(diào)用 Ward的模塊，他們可能會喜歡該模塊的API。我的模塊缺陷率很低也許會給他們留下印象。不過他們可能會說，“他的模塊很簡單。他有一個容易編寫的模塊，這就是為何他的缺陷率這么低?！彼麄儾粫勒嬲脑颉?

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

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

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

　　Ward Cunningham：我肯定也會這樣。

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

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

解決紛爭

　　Bill Venners：在“Extreme Programming Explained”一書中， Kent Beck寫道，“集體所有權(quán)增強(qiáng)了在項(xiàng)目中對個人能力的認(rèn)知。您不會永遠(yuǎn)釘住別人的蠢事不放。您在途中發(fā)現(xiàn)了某些東西，然后把它排除掉?！睂τ谑裁词谴朗氯绻煌说目捶ɑハ嗝軙r該怎么辦？所謂蠢事不是一種主觀的評價嗎？

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

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

　　Bill Venners：您是說再回到A。

　　Ward Cunningham：如果需要的話。

　　Bill Venners：也可能是到C。

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

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

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

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

變更的成本

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

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

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

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

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

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

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

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

對未來的預(yù)測

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

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

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

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

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

　　Bill Venners：為了批駁變更成本曲線，您發(fā)現(xiàn)了一種方法可以在項(xiàng)目的整個生命期中進(jìn)行變更。這就使得對將來的計劃不那么重要了，因?yàn)榭梢栽谝院笳嬲枰归_的時候進(jìn)行變更。整個體系結(jié)構(gòu)僅僅是在每次只關(guān)注一小步的過程中逐漸浮現(xiàn)出來的嗎？

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

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

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

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

　　wiki一詞來源于夏威夷語的“weekee weekee”，原本是“快點(diǎn)”的意思。在這里wiki指一種超文本系統(tǒng)。這種超文本系統(tǒng)支持面向社群的協(xié)作式寫作，同時也包括一組支持這種寫作的輔助工具。我們可以在Web的頁面上對wiki文本進(jìn)行瀏覽、創(chuàng)建、更改，而且創(chuàng)建、更改．發(fā)布的代價遠(yuǎn)比HTML文本為??；同時wiki系統(tǒng)還支持面向社群的協(xié)作式寫作，為協(xié)作式寫作提供必要幫助；最后，wiki的寫作者自然構(gòu)成了一個社群，wiki系統(tǒng)為這個社群提供簡單的交流工具。與其它超文本系統(tǒng)相比，wiki有使用方便及開放的特點(diǎn)，所以wiki系統(tǒng)可以幫助我們在一個社群內(nèi)共享某領(lǐng)域的知識。

　　1995年Ward Cunningham為了方便模式社群的交流建立了一個工具——波特蘭模式知識庫(Portland Pattern Repository)。在建立這個系統(tǒng)的過程中，Ward Cunningham創(chuàng)造了Wiki的概念和名稱，并且實(shí)現(xiàn)了支持這些概念的服務(wù)系統(tǒng)。這個系統(tǒng)是最早的wiki系統(tǒng)。從1996年至2000年間，波特蘭模式知識庫圍繞著面向社群的協(xié)作式寫作，不斷發(fā)展出一些支持這種寫作的輔助工具，從而使wiki的概念不斷得到豐富。同時wiki的概念也得到了傳播，出現(xiàn)了許多類似的網(wǎng)站和軟件系統(tǒng)。

• 維基經(jīng)濟(jì)學(xué)
• 吉米·威爾士（Jimmy Wales）是維基百科創(chuàng)始人之一，現(xiàn)為維基媒體基金會理事會榮譽(yù)主席。
• 拉里·桑格（Larry Sanger）另一個維基百科創(chuàng)始人