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

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

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

　　他1995年在波特蘭模式知識庫創(chuàng)建了第一個Wiki站點。這個站點現(xiàn)在還在運作，致力于“人，項目和模式”，并且是一個“程序設(shè)計語言思想的非正式歷史”。例如，這個站點被用來為有用的軟件開放的模式語言以及極限編程的軟件方法的發(fā)展進行分類?？矊幇蔡岬絎iki的概念是他在20世紀(jì)80年代末期想到的，并且他首先使用HyperCard堆棧的方法進行實現(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è)計，以及由他的WikiWikiWeb提供的社團。他還是“山坡組”的創(chuàng)始人，并且作為其贊助的“程序的模式語言”會議的程序主席。

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

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

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

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

　　從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），編輯與組織文件的機制，應(yīng)該與書寫時相同，因此書寫者同時也可以是編輯、編纂者；明顯（Observable）表明了網(wǎng)站內(nèi)的行為必須受到該網(wǎng)站其他的瀏覽者檢閱；集中（Convergent）重復(fù)的內(nèi)容借由類似與相關(guān)內(nèi)容的引用後，可以進行移除。

　　(記者/Bill Venners：在軟件社區(qū)中，Ward Cunningham享有思想源泉的美譽。他發(fā)明了CRC Cards，這是改進對象發(fā)現(xiàn)的一種技術(shù)。為了促進軟件模式的發(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)驗，從而發(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)一段很好的信息，于是就想，“好極了，為什么沒有人哪怕只是把那些好的片段作一個清單，我就不用再搜索其他的部分了?！睋Q句話說，“為何沒有人組織一下，讓我迅速找到問題的答案？”早晚他們的想法會得到實現(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軟件問題的人交流，這有很大的不同。 　　

集體的代碼和文本

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

　　Ward Cunningham：這樣做完全是有意的。在設(shè)計wiki前的幾個月中，我們有過一次爭論。我認(rèn)為Kent Beck和我站在一邊。堅信主流軟件工程教條的那些人站在另一邊。我們說“集體代碼所有權(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)用于程序。為什么？因為知識的發(fā)展和在擁有這些知識之前做出的某些組織決策相沖突。換句話說，程序抗拒知識的積累。

　　Bill Venners：抗拒？

　　Ward Cunningham：程序?qū)δ撤N類型的知識有抵抗力——沒有預(yù)計到的知識——因為很難在一開始就設(shè)立的結(jié)構(gòu)內(nèi)表達這些知識。很難把不符合這種結(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是為人類編寫的，沒有精確的解釋。我可以說，“哎呀，我可以把這個句子放在這兒，并砍掉一半，因為在這個上下文中很容易理解?！钡俏铱赡苠e了。對于我容易理解，但可能對其他人很難，我也沒法做測試。因此在重構(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)了某些東西，然后把它排除掉?！睂τ谑裁词谴朗氯绻煌说目捶ɑハ嗝軙r該怎么辦？所謂蠢事不是一種主觀的評價嗎？

　　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ā)人員說，“你知道，這些代碼令我感覺不舒服?！蔽艺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)プ?，就讓我們做完它吧。”他們做了一個巨型項目，以前從未有這樣的經(jīng)驗。你猜怎么樣？他們錯了。相反，我們每周都在做。每周做一點。我們確實從中受益了。我們永遠(yuǎn)不會害怕它。它也從來沒有出現(xiàn)問題。

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

變更的成本

　　Bill Venners：在“Extreme Programming Explained”一書中，Kent Beck寫道，“軟件工程中一個普遍的假設(shè)是程序修改的成本隨著時間呈指數(shù)級增長?！辈⒔ㄗh說，“通過技術(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ù)言未來很簡單。科學(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)?！蹦敲大w系結(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)。

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

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

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