沃德·坎寧安
出自 MBA智库百科(https://wiki.mbalib.com/)
目錄 |
Ward Cunningham全名為 Howard G. Cunningham，中文譯名沃德·坎寧安（或沃德·坎寧漢）。現居住於俄勒岡州的波特蘭。
沃德·坎寧安是一名著名的電腦程式員，模式研究和極限編程有較大影響。坎寧安幾乎涉獵過所有的編程模式，包括面向對象和敏捷建模。同時，他是wiki概念的發明者，並建立了第一個wiki網站波特蘭模式知識庫。
沃德·坎寧安從普度大學獲得（電子工程和電腦科學的）交叉學科工學學士學位以及電腦科學的碩士學位。
他1995年在波特蘭模式知識庫創建了第一個Wiki站點。這個站點現在還在運作，致力於“人，項目和模式”，並且是一個“程式設計語言思想的非正式歷史”。例如，這個站點被用來為有用的軟體開放的模式語言以及極限編程的軟體方法的發展進行分類。坎寧安提到Wiki的概念是他在20世紀80年代末期想到的，並且他首先使用HyperCard堆棧的方法進行實現。
他是《The Wiki Way》（2001年）這本書的作者（與Bo Leuf合著）。
他是Cunningham & Cunningham, Inc.公司的創始人。他還是Wyatt Software研發部門的總裁，以及Tektronix Computer Research Laboratory的主要工程師。沃德·坎寧安之所以聞名的是對面向對象程式設計的開發實踐的貢獻，這個變種叫做極限程式設計，以及由他的WikiWikiWeb提供的社團。他還是“山坡組”的創始人，並且作為其贊助的“程式的模式語言”會議的程式主席。
2003年12月，沃德·坎寧安加入微軟，為微軟的“模式與實踐”組工作。從2005年10月開始他轉入Eclipse基金會。
坎寧安自陳wiki的想法源自1980年代後期，“我創建第一個Wiki的初衷就是要建立一種環境，我們能夠交流彼此的經驗。”。並且他首先使用HyperCard（一個資料庫圖示軟體）堆棧的方法進行了離線wiki的試驗。
1995年，坎寧安在Purdue大學計算中心工作時，為了方便模式社群的交流建而建立了一個工具——波特蘭模式知識庫（Portland Pattern Repository）。在建立這個系統的過程中，沃德·坎寧安創造了wiki的概念和名稱，並且實現了支持這些概念的服務系統，這就是最早的wiki系統（建立時間：1995年3月25日）。
波特蘭模式知識庫現在還在運作，致力於“人，項目和模式”，並且是一個“程式設計語言思想的非正式歷史”。例如，這個站點被用來為有用的軟體開放的模式語言以及極限編程的軟體方法的發展進行分類。
從1996年至2000年間，波特蘭模式知識庫圍繞著面向社群的協作式寫作，不斷發展出一些支持這種寫作的輔助工具，從而使Wiki的概念不斷得到豐富和傳播，併在網路空間出現了許多類似的網站和軟體系統，其中最有名的就是維基百科。
坎寧安曾列舉了若幹wiki的設計原則，其中較為重要的如：開放（Open），當網頁內容不完整或未加以適當組織時，所有人都可以以他們認為適當的方式加以編輯；遞增（Incremental），網頁可以引用其他網頁，甚至包括那些不存在的文件。普遍（Universal），編輯與組織文件的機制，應該與書寫時相同，因此書寫者同時也可以是編輯、編纂者；明顯（Observable）表明瞭網站內的行為必須受到該網站其他的瀏覽者檢閱；集中（Convergent）重覆的內容藉由類似與相關內容的引用後，可以進行移除。
(記者/Bill Venners：在軟體社區中，Ward Cunningham享有思想源泉的美譽。他發明瞭CRC Cards，這是改進對象發現的一種技術。為了促進軟體模式的發現和編檔，他發明瞭世界上第一個wiki，一種基於web的協同編寫工具。許多極限編程（Extreme Programming）技術背後的主要靈感也被歸功於Cunningham。)
- 為什麼需要Wiki？
Bill Venners：您發明wiki的最初目的是什麼？
Ward Cunningham：我創建wiki要完成幾件事。第一個wiki的初衷是要建立一種環境，我們能夠交流彼此的經驗，從而發現編程的模式語言。我以前曾經使用過HyperCard組，它基本上也是為了類似的目標。我知道人們喜歡使用那種HyperCard組來閱讀和創作，但它是單用戶的。當開始PLoP （編程模式語言）系列討論會的時候，我們認識到我們真正想要做的是開始編寫一部新的作品，我認為我需要使用HyperCard組，並希望能找到一種應用於 web的等價物。
對於wiki，我還有更多通用的目標。首先，人們常說“人人喜歡講話”，我認為這裡面有一種令人信服的人類本性。在創建wiki時，我希望激發每個人喜歡講故事的天性。其次，也許是最重要的一點，我希望不經常創作的人們會發現創作非常輕鬆，這樣就有機會發現創作的結構和方法。
Bill Venners：wiki如何使創作變得輕鬆？
Ward Cunningham：不熟悉寫作的某個人可能有一個想法，這個想法值得寫成一段。他們本來可以為雜誌寫一篇評論，但是一段文字太短了。為了給雜誌撰寫文章，他們不得不介紹一下背景，講述某些重要的東西，而且要以多數人都能理解的方式講述，然後結束文章。太複雜了，多數人都不願意花費那麼多的精力。
但是如果您正在閱讀別人的作品，並想到“是的，但是還有一點”可以放在一段中這樣說，“啊，不錯，但實際上還有……”在wiki上有很多這種類似於“對，但是……”的對比想法。討論組也作了同樣的事情，但是在討論組中這些對比都丟失了。
Bill Venners：為何在討論組中丟失了？
Ward Cunningham：因為沒有上下文，無法持續下去。討論組往往反覆圍繞著同一個話題，但是人們忘記了以前說過什麼。我認為，常見問題解答（FAQ）的發明就是針對這個問題的。很多時候，讀一讀FAQ要比參加討論組更有意義。在一開始做wiki的時候，有一個系統叫FAQ-O-Matic，它和wiki 的想法一樣，只不過其真正的目的是製作FAQ。我看到它的時候就想“哦，英雄所見略同”。不過我接下來又想，“不，我更喜歡面向文檔的形式而不是問答形式。”在我們的作品中想要創建的模式是某種類似FAQ的東西，但應該不止如此。現在，wiki上可能有10,000到15,000種模式，25,000頁文檔。
Bill Venners：您認為wiki適合做什麼？wiki的高明之處在哪裡？
Ward Cunningham：如果您試圖回答一個不容易闡述的問題，事先不瞭解某種應該知道的自然結構，wiki會非常有用。對於像“項目進展如何”之類的問題，我們可以設計一個資料庫。但是資料庫中要放哪些欄位還要歸結到對項目進展問題什麼是重要的。關於項目的哪方面重要這些資料是不可預見的。
Wiki頁面的格式非常自由。在整個wiki中有一個超文本結構，但是在一個給定的頁面上，在自然語言靈活性的許可範圍之內，您可以講任何想要述說的東西。因此，wiki是跟蹤項目進展狀態的一種良好方式。比方說，您可以把我的模式作品看成是一個長期進行的項目。我們不知道終點在那裡，但是我們希望在進展中發現它。
此外，wiki也非常適合於想要把控制權交給系統用戶的環境。在wiki中並沒有多少何人何時可以做何事的邏輯，因為wiki並不真正理解您在做什麼。它只是為您保留頁面。關於什麼是適當的用法什麼是不好的用法，已經建立了大量的慣例，但這些都存在於用戶的頭腦中，而不是在應用程式的業務邏輯中。如果您有一個可靠的團體，不謀求通過電腦強制某種行為，wiki就可以很好地工作。比如，有人曾經問我wiki是否適用於協同環境。我認為某些公司對它們的雇員完全具備這種信賴，某些公司則沒有。不信賴雇員的公司可以根據某些需要維護一個web站點而不是wiki。
- 把握大局
Bill Venners：讀者如何把握wiki上的總體內容？
Ward Cunningham：首先要理解，因為我們使wiki更方便作者，實際上就增加了讀者使用的難度。裡邊有某種組織方式，這種組織方式還可以改進，但它不是組織嚴密的。因此讀者就會感到仿佛是在茫茫的一片信息片段中搜尋。偶然發現一段很好的信息，於是就想，“好極了，為什麼沒有人哪怕只是把那些好的片段作一個清單，我就不用再搜索其他的部分了。”換句話說，“為何沒有人組織一下，讓我迅速找到問題的答案？”早晚他們的想法會得到實現，“哎呀，行了！”他們花了一個月或者兩個月查找所關心的東西，然後做一個頁面，wiki組織成什麼樣子由他們自己承擔。
我不是一個分類的痴迷者。如果感興趣的事物不符合需求或者不是預期的，定義一個有用的分類方案非常困難。不過有些人認為每個頁面都應該帶有分類。他們帶著一個分類方案，根據頁面的名稱，為wiki建立分類結構。這些註重分類的人負責維護它。如果某人創作了一個不能歸類的頁面，其他的人就會說，“哦，這應該歸為wiki保留頁面或者設計模式。”
Bill Venners：如何把一個頁面歸類為wiki保留頁？
Ward Cunningham：只需對一個叫做WikiMaintenanceCategory的頁面進行引用。單擊該鏈接時，就會轉到那一頁，對這種分類進行解釋以及為何有這一類。因此把頁面歸到某一類，習慣上是增加到該類別描述頁的鏈接。這樣標記了該頁。如果要瞭解這一類是什麼，可以沿著鏈接到類別描述頁。如果要看看這一類中有什麼頁面，可以搜索引用該類別頁的所有頁面。
Bill Venners：我猜想搜索也許是研究新wiki的一種方式。從一定意義上講，wiki類似於一種小型的internet。 一切都分散在各處。如何發現正在尋找的內容呢？我可以從搜索關鍵字開始。
Ward Cunningham：是的。任何名稱以“Category”結尾的wiki頁都是一個值得搜索的條目。可以通過Google搜索小說，但是如果有人不把作品標記為小說，就找不到它。分類系統是一組頁面，解釋分類的基本原理，可以讀讀這些頁面。它們使用了名稱空間的一小部分——所有這些詞都以 “Category”結束——並建立了這些頁面涉及其他頁面分類的實例。非常棒。還在發展中。如果我要做一個解決方案，可能會非常簡單，甚至同樣好。我最喜歡的一點是，有一個非常積極的社區在管理這些分類。有時他們把分類搞錯了，但很快就會糾正過來。
- Wiki中的時間要素
Bill Venners：您所說的有點讓我想起“自由討論”。您把一些人集合起來充實那些您還不完全清楚的事物。
Ward Cunningham：Wiki有點像“自由討論”，儘管不是互動式的。您可以做10分鐘的自由討論，用30分鐘分析自由討論的成果，然後在45分鐘之內完成某件事。Wiki的腳步要慢一些。您可以就某個觀點寫一個頁面，或者就很多想法寫一個頁面。然後在一周之內回來看看頁面上有什麼進展。但是如果在15 分鐘之內回來，不會發生太多的變化。Wiki上的事情是以天或者周為周期的，因為人們往往每天或每周瀏覽一次。
Wiki中有一個有趣的時間特性。讀新聞組或者郵件列表時，會有一種感覺，當前就是您在列表中的位置。我不希望wiki中有一個時間表。當在讀wiki上的某些內容時，我不希望時間會影響您，不論它是一年前寫的還是一天或者一分鐘前寫的。這意味著我們需要通過某種方式得到上下文。
如果您正在編寫一個頁面，那個頁面必然和其他某個頁面有關。因此所要做的就是，在一個段落中說明其他頁面中哪一些是關於這個上下文的。人們逐漸熟悉這些頁面的名稱。他們遇到一個新的頁面，閱讀包含對上下文頁面鏈接的段落。如果已經度過這些頁，就繼續讀下去。如果不知道這些頁，他們就會說，“哦，這一頁沒有什麼意思。我還得讀一讀其他的頁。”這樣如果您瞭解上下文的話，就不必再去看了。但是如果不瞭解上下文，您可以去看一看。上下文不會變。
Bill Venners：聽起來似乎您必須瞭解wiki站點。過一段時間後您就會熟悉它了。一開始可能會令人感到困惑，也沒有多少提示，您進來發現到處都是這樣的內容，但不一定是根據讀者的需要組織的。
Ward Cunningham：對，wiki總是在不斷地組織中。每花費一個小時組織，都要花費另外兩個小時來增加新的材料。因此wiki的總是處於半組織化狀態。
- Wiki 和可讀性
Bill Venners：我確實非常喜歡wiki的思想，但是我發現閱讀許多wiki頁非常困難。可讀性的問題是我一直沒有在Artima.com上增加wiki 的主要原因。Artima.com也是一種基於web的協作文檔，但是更加結構化。在wiki中沒有專職編輯為讀者組織材料。所有的頁面都是協作性的。結構是協作性的。編輯是協作性的。從wiki的協作性中有什麼足以抵消可讀性的損失？
Ward Cunningham：作為wiki讀者，您能夠獲得以前沒有發言的那些人的觀點。聽我們發言的人對於怎樣編寫和發佈電腦程式有直覺的想法。我們這一行在發表過程中對傳統保留了某些尊重。比如，如果您想為一本科學雜誌投稿，應該經過同行評審。同行評審的一部分是你應該熟悉所有其他作品。而其他作品可能糾纏進某些細枝末節。關於編程的作品有時並不符合程式員的實際感觸。有了wiki，沒有時間學習寫作併在雜誌上開闢專欄的實踐程式員，就有機會講出那些對於他們來說是重要的事情。Wiki提供了一個不同的視角。事實上，您可以分辨出一個人是在wiki上根據自己的經驗創作，還是轉述剛剛讀到的東西。
Bill Venners：那麼您怎麼分辨呢？
Ward Cunningham：您可以根據他們談論事情的方式來區分，比如“Mary Ann就是做不好這一部分。”這不符合科學傳統。如果有人引述某位作者的話，“某某怎麼說，你這家伙怎麼聽不明白”，有人在贊美他所讀的書。另一方面，如果有人說，“您知道，在以前的三個項目中我們都嘗試過，但一次也沒成功，我們只能用別的辦法擺平它。”有個家伙解決了這個問題，他正在跟我談一些深刻的問題。如何解釋要靠我自己。這隻是他的經驗。然後您可能還會看到其他幾段文字，“是的，我也遇到過，我用這種方法搞定了。”那麼現在就有兩種方法了。突然之間，您開始與解決了軟體問題的人交流了，而不是和談論解決軟體問題的人交流，這有很大的不同。
- 集體的代碼和文本
Bill Venners：極限編程（XP）的集體代碼所有權特點讓我想到了wiki，在wiki中，每個人對所有一切負責。
Ward Cunningham：這樣做完全是有意的。在設計wiki前的幾個月中，我們有過一次爭論。我認為Kent Beck和我站在一邊。堅信主流軟體工程教條的那些人站在另一邊。我們說“集體代碼所有權很好。”他們則說“太荒謬了。沒有職責劃分，而沒有責任就決不會有質量。讓他們避免製造缺陷，就必須把缺陷和某個人掛鉤。”我說，“完全不對。”
我設計wiki的決定，很大程度上受到建立一種協同過程模型的渴望所啟發，我認為在大型代碼庫中應該有這種協作。我希望wiki能夠模擬這種情況。比方說在一堆代碼中有一個問題。您知道怎麼解決問題，但是解決需要涉及到大量模塊。重構需要大量艱苦的工作，如果要同每個最初的作者協商就更加困難。你只是希望改正問題。
困難在於代碼可能是按層次結構組織的，但是解決方案可以從多方面來考慮，而不止是某種層次結構。因此當您在某一方面發現一種貫穿整個層次結構的解決辦法時，您只能隨著解決方案的要求，在適當的地方加入解決方案。我們經常發現自己處於這樣一種境地，人們瞭解這個程式，但是他們不能將這些知識應用於程式。為什麼？因為知識的發展和在擁有這些知識之前做出的某些組織決策相衝突。換句話說，程式抗拒知識的積累。
Bill Venners：抗拒？
Ward Cunningham：程式對某種類型的知識有抵抗力——沒有預計到的知識——因為很難在一開始就設立的結構內表達這些知識。很難把不符合這種結構的任何東西加進去。
Wiki中也有一點對預料之外思想的抗拒，但這種抗拒主要在人們的實踐中。Wiki中寫進去的東西越多，對自身權利的要求越嚴格，但是如果有人要修改而且到第25頁去修改，他們就可以去25頁。
比如，在wiki中，發生的某個過程是頁面從討論發展成短文。許多人願意閱讀討論。那些每天訪問wiki的人希望看看昨天又說了什麼，因此需要按時間組織的頁面。但是對學習而言，投稿先後順序並不是一種很好的組織原則。因此頁面總是保持某種討論之中的感覺，直到這個討論結束。後來，有人又回來閱讀了這些討論，把您可能稱之為線性模式的頁面重新組織成文檔模式的頁面。
如果在註解之間轉來轉去，而且有許多類似的彼此相鄰的註解，您經常會發現可以去掉一大半篇幅。因為只要位置適當，一句話可能就說明白了。在Ward的 wiki上，這個過程被稱為“重構（refactoring）”，就像我們在軟體中那樣稱呼這個過程。Ward的wiki是關於軟體的，其中有許多從事軟體的人，因此稱為重構。在其他地方可能就會稱為“編輯”了。在Ward的wiki上，重構是一個持續的過程。設想如果某些地方被證明不很合適，就要再次進行重構。一切都是重構的目標。這也是我們願意在軟體中所看到的。
軟體的優勢是它有明確的解釋。因為軟體是為機器編寫的，我們可以依靠精確的解釋編寫測試。在重構程式時，我們可以測試沒有破壞或者丟失的任何東西。但 wiki是為人類編寫的，沒有精確的解釋。我可以說，“哎呀，我可以把這個句子放在這兒，並砍掉一半，因為在這個上下文中很容易理解。”但是我可能錯了。對於我容易理解，但可能對其他人很難，我也沒法做測試。因此在重構過程中，我們可能會丟失wiki上的某些信息。Wiki像一個信息漏桶。它每天都在丟失信息。但是有更多的信息加進來，因此凈結果是正的。即使丟失了某些東西，wiki總是比昨天有更多的內容。
- 高質量代碼的集體激勵
Bill Venners：從您的描述中我瞭解了集體代碼所有權的好處。但代價是什麼？集體代碼所有權的缺陷是什麼？
Ward Cunningham：我相信有一些缺陷，但是現在還沒有想到。
Bill Venners：所有權的自豪感又如何？人類適應集體自豪感嗎？在您自己創建什麼時，總是希望把它做好。
Ward Cunningham：我認為集體所有權實際上更好一些。是的，我對自己所做的事情感到自豪。對於我而言，自豪感是一種激勵。通過集體所有權，我們基本上建立了一種小型的社區，訓練他們自我肯定所做的工作。但如果歸我所有，人們就會說，“那是Ward的模塊，我不想看Ward的模塊。”如果必須調用 Ward的模塊，他們可能會喜歡該模塊的API。我的模塊缺陷率很低也許會給他們留下印象。不過他們可能會說，“他的模塊很簡單。他有一個容易編寫的模塊，這就是為何他的缺陷率這麼低。”他們不會知道真正的原因。
當人們使用我提供的材料時，他們會感覺到是否容易使用。所謂使用材料，我是指拿來代碼調整，以便做更多一點工作或者稍微改變其功能——這些代碼應該做的任何事情。當人們使用代碼時，他們會看到我努力完成的一些事情，否則的話他們永遠也不會註意到。不需要迫使他們說“Ward你很了不起”，但有時候他們會說，“Ward你很了不起。”這就滿足了我的自負感。所有權的自豪感？的確如此。
現在，不需要在每一行上寫上我的名字。事實上，這證明如果它確實很好，可能是因為他們做得好，而不是我。我可能只是做了一個計劃，然後他們完成了而且完成得很好。我可能會受到不應得到的榮譽，不過他們也可能把贊譽送給別人。一個想法來自誰，榮譽應歸誰，這種觀點是彈性的。但我認為人們在知道誰參與其中的時候，可以很好地解決這種彈性，承認每個人的貢獻。通過集體所有權，我們建立了一種社會環境，通過源代碼語句中迸發的智慧可以瞭解一個人。
Bill Venners：集體所有代碼的這種特點為何不能出現在wiki頁面上，wiki頁面上的內容有時候顯得有點亂？
Ward Cunningham：我肯定也會這樣。
Bill Venners：您剛纔談到某一行代碼是誰編寫的並不總是很明顯。對於wiki頁面也是如此。誰寫了某一行文本也並不總是很明顯的。有時候一個人在 wiki頁面上寫了一些東西，“我有這樣的經驗”，而作為讀者我並不知道這個“我”到底是誰。集體代碼所有權和集體文本所有權相比有什麼不同，您剛纔只談到了代碼而沒有涉及文本？
Ward Cunningham：我認為不可預料的代碼是很常見的。代碼可能能夠工作，但如何工作本質上是秘密的，不可能閱讀。事實上，這也可能是一種常見情況。因此混亂可能不夠確切，應該是不可讀。我有與他人長期結對編程的經驗，在讀到他們的代碼時，甚至認為是自己的代碼。但在wiki上還沒有出現這種情況，我讀到某人的文字而認為是自己寫的。這可能是因為代碼具有更高的組織性，但我認為更可能是因為代碼交流的範圍更狹窄。代碼交流的範圍僅限於某種過程的電腦化，而談話的最佳方式是相當廣泛的。這樣就會導致和英語相比，代碼會更快地具有穩定的組織性。
- 解決紛爭
Bill Venners：在“Extreme Programming Explained”一書中， Kent Beck寫道，“集體所有權增強了在項目中對個人能力的認知。您不會永遠釘住別人的蠢事不放。您在途中發現了某些東西，然後把它排除掉。”對於什麼是蠢事如果不同人的看法互相矛盾時該怎麼辦？所謂蠢事不是一種主觀的評價嗎？
Ward Cunningham：啊，我決不會這樣說。當我認識到不需要贏得每一次爭論的時候，這是我編程生涯中的一個轉折點。我正在和別人討論代碼，我說“我認為最好的做法是A”，他們則說“我認為最好用B”。我說“不，應該是A”，他們則堅持說“我們想用B”。當我能夠這樣回答的時候，對我而言這是一個轉折點： “好吧，用B辦法。如果我錯了這樣就不會損害我們。如果我對了，而您用B辦法也不會造成多少損害，因為我們可以改正錯誤。讓我們看看這樣做是否錯了。”
我們不要把自己看成非常幸運的預言者，要求自己預測未來。最好是建立一種環境，這樣您就能夠試一試B並看看發生什麼。現在證明爭吵通常是無益的。無論誰編程，都可以自由選擇編程的方式，這樣就足夠了。當然有時候也可能會證明爭論是有用的。我們正在做別的事情，看了看說，“您知道，用在那裡並不合適，因為B 確實不符合。”而這個問題可能是我在宣傳A方法時正好考慮到的，也可能不是。它可能是開發人員在方法B的上下文中硬塞進去的。但有時候您瞭解這些缺陷或者難以改進的地方。於是開發人員說，“你知道，這些代碼令我感覺不舒服。”我說“好吧，我可以解決這個問題”。他們問道“您行嗎？”我說，“當然，我可以解決這個問題。您做了B，我就使用B。”然後我就可以開始處理它，只要可能就儘量使用B。但是因為承擔了職責，我就有機會使它實現需要的功能。
Bill Venners：您是說再回到A。
Ward Cunningham：如果需要的話。
Bill Venners：也可能是到C。
Ward Cunningham：通常會變成C。對於我們雙方這都是一種學習的經歷。如果沒有這種經歷，我們就都沒有學到什麼。Ward贏了，其他人輸了。或者相反。這和一場戰爭差不多。為什麼不說，“好吧，讓我們編碼看看怎麼樣。如果不行的話我們再改變。”
我無法告訴你我花費了多少時間擔心無關緊要的決策。如果能夠做一項決策，然後看看結果如何，當然會大大減少這種擔憂，但是這意味著您必須建立一種環境，當確實出問題時可以修正。如果某些事情確實出了問題，不會浪費您和您的客戶過多的成本。這不是一種可笑的花費。如果您處於不能承受錯誤的情況下，就很難做正確的事情。因此如果嘗試做正確的事情，正確的事情可以抵消犯錯誤所造成的代價，要遠比猜測什麼是正確的好。
比如，在一個項目中我們通過經常升級抵消了錯誤成本。我們是通過建立一個相當精細的資料庫模式演化機制實現的。。我們曾經每周發佈一次，每周都修改模式。我們可以為不同的客戶根據不同的要求對模式作不同的修改，把這一切結合起來最終得到正確的結果。因為我們每周都在做，大約六周或八周以後，我們就確信我們可以完成它了。我們從沒有擔心過。多數人都說，“無論做什麼，千萬不要做模式演化除非你已經做了。”但在項目結束的時候，他們說，“天哪，我們真的做到了。”因此在從來沒有做過之前，他們說，“只要我們去做，就讓我們做完它吧。”他們做了一個巨型項目，以前從未有這樣的經驗。你猜怎麼樣？他們錯了。相反，我們每周都在做。每周做一點。我們確實從中受益了。我們永遠不會害怕它。它也從來沒有出現問題。
因此我們不是通過說“我們要做的工作性質就是這樣”，從而通過抹去問題來解決問題。要是這麼簡單的話才是真的奇怪了。實際上更多的是提問的方法，“您希望擅長什麼？”，如果您希望擅長它，就找出一種方法來每天應用它。如果每天都要應用，那麼就只能熟練掌握了。因此，選擇您希望擅長什麼。您應該擅長您所害怕的東西，這樣您就不會再害怕它了。
- 變更的成本
Bill Venners：在“Extreme Programming Explained”一書中，Kent Beck寫道，“軟體工程中一個普遍的假設是程式修改的成本隨著時間呈指數級增長。”並建議說，“通過技術和編程實踐的結合，有可能得到一條方向相反的曲線。”怎麼能夠實現變更成本曲線的扁平化呢？
Ward Cunningham：傳統上來說，變更成本曲線告訴我們，早發現變更的需要與晚發現這種需要相比，進行變更所花費的代價越小。我批判了這種曲線，因為根據這種理論，我們差不多可以故意犯錯，然後在實踐中改正錯誤，這樣有助於減少以後變更的成本。
我們認為，任何變更的決定因素不是何時進行變更，而是需要做多少思考。如果我們每周做一次變更，而理解我們的真正需要花費了兩天，那麼做這種變更就需要兩天。如果我們每21周變更一次，理解我們的真正需要也花費兩天時間，那麼這個變更也用了兩天。
在每周一次的變更中，我們可能要寫20條語句。在21周變更一次時，我們可能需要寫20條語句並修改4條語句。但是如果您習慣於變更，修改4條語句也花不了多少時間。只需要找到那些語句並修改它，可能只需要1分鐘。
因此理解變更的需要是決定性因素。編程實現變更並不重要。只要我們理解了變更，我們就可以編程實現，或早或遲。修改代碼的實際成本並不在編程中占有主導地位。主要的成本是理解所花費的時間，這就給出了一條趨向平緩的變更成本曲線。
許多人害怕變更，是因為儘管在編寫的時候還理解代碼，但這種理解很快就消失了。他們對你說，“我們為這些語句費盡了心血，無論如何不要改變這些語句！”他們並不想回到原來的代碼，因為重新理解太費勁了。因此使變更成本曲線扁平的另一種方法，即以後變更的成本不會比現在更大，就是確定人們必須能夠看到他們將要改變什麼並理解它。因此，當你在編寫代碼時，你就會更多地為將要閱讀代碼的人編寫，而不是為運行它的機器編寫。
同樣，你也不願意編寫大量的註釋，告訴別人如何進行他們所需要的修改，因為您並不知道他們要進行何種修改。最好抱有這樣一種觀點，您不能幫助將來的程式員進行修改。您所能做到的就是使他們容易理解您努力去做的事。如果您非常小心，避免做太多的事情，這樣最有助於他們理解您的努力。您試圖完成的功能越多，將來的程式員要理解您的代碼就越困難。
比方說，如果您明顯地忽略了一種情形，以後的程式員需要解決它，他們打開代碼發現您顯然是忽略了這種情形。這意味著他們可以自由實現需要的任何功能。但是如果您試圖應付這種情形，他們來了首先要確定哪裡不工作。他們將看到您試圖解決這種情況，因此他們首先要嘗試理解您在做什麼。一旦理解了您要做什麼，他們就可以指出如何修改以實現需要的功能。他們更願意接手的時候發現您甚至沒有考慮到這一點。也許您想到了，但完全沒有對此編程。
- 對未來的預測
Bill Venners：每個人都同意預測未來是很困難的，但預測總是這麼糟嗎？
Ward Cunningham：在科學中預言未來很簡單。科學建立在對物理系統行為研究的基礎上，被證明具有驚人的可預言性——可能天氣除外。我們已經能夠向太空發射火箭並使它沿軌道運行，這是預測的一個範例。但是當開始談及對未來的期望時，我們可能有某些直覺，這些直覺也許是對的，但不會總是對的。我們必須考慮到不正確的情況。
當一個新的需求出現時，我們看了看說，“好的，這不難。這個程式就是為它而作的。”我們在程式中加入一些代碼，然後就成了——我喜歡這樣。我討厭這種情況，新需求的出現不能很好地滿足，仿佛程式的設計就是為了和需求作對。這種情況下，我們有大量的工作要做。但是這項工作的性質要求首先修改程式使它更容易適應新的需求，然後把新的需求包含進來就很容易了。換句話說，不是為新的需求在並不適合這種需求的結構上打補丁，而是全力以赴做艱難的任務修改結構，使它能夠很容易實現這種需求。打補丁的辦法意味著，後來者不但要理解並非為這種需求設計的系統，還要理解試圖彌補但不改變系統的那些補丁。最好是修改系統以便很容易適應新的特性。
有人也許會說，“為什麼不向前看一看，瞭解我們必須做到的所有工作呢？為什麼不從一開始就把系統設計成使所有工作更方便呢？”如果您能夠實現這樣一個系統，那真是太好了。正是這樣，人們一次又一次地試圖設計系統使明天的工作更容易。但是當明天到來時，卻發現他們並沒有很好地理解明天的工作，實際上他們使明天的工作更難了。
- 意外的體繫結構
Bill Venners：為了批駁變更成本曲線，您發現了一種方法可以在項目的整個生命期中進行變更。這就使得對將來的計劃不那麼重要了，因為可以在以後真正需要展開的時候進行變更。整個體繫結構僅僅是在每次只關註一小步的過程中逐漸浮現出來的嗎？
Ward Cunningham：我喜歡塑造程式這種說法，就象藝術家塑造一團泥巴一樣。藝術家想做一個雕塑，但是在開始雕塑之前，她只是把泥巴揉來揉去。她開始逐漸塑造成形，並看到泥巴要成為什麼樣子。揉捏得越多，泥巴就越像她希望的樣子，最終變得完全符合她的想法。
一個開發小組用了數月編寫一段代碼。最初，他們做了一段代碼，有點僵硬。代碼很短，但仍然有點僵硬。他們攪動這些代碼，代碼稍微變軟了點。在上面提到的一個項目[第II部分]中，我們向資料庫增加了模式演化功能。它軟化了程式，變更容易多了。每次變更模式時，我們都作一點改進。程式員和代碼——作為一個整體——都軟化了。我們塑造程式並保持它的柔軟性。
在項目結束時您已經完成了需要做的所有事情——有人為之付錢的所有功能——您看了看代碼問道，“這一堆東西中的核心是什麼呢？這是怎麼完成的？我們日復一日地編寫程式，它是怎麼結束的呢？”通常程式的結束都是令人驚詫的。您會說，“這是一種優美的結構。”那麼體繫結構又從何而來呢？
在這裡，體繫結構意味著我們處理不同需求的系統化方式。當我們根據需要塑造程式時，體繫結構使我們能夠發現進展到哪裡了。融入程式的是一個系統，包括我們所做的每一個小決策——正確的小決策，錯誤但改正了的小決策。從某種意義上講我們得到的這個體繫結構並沒有經過嘗試。在其他決策上下文中的所有決策凝結成了一種體繫結構。
wiki一詞來源於夏威夷語的“weekee weekee”，原本是“快點”的意思。在這裡wiki指一種超文本系統。這種超文本系統支持面向社群的協作式寫作，同時也包括一組支持這種寫作的輔助工具。我們可以在Web的頁面上對wiki文本進行瀏覽、創建、更改，而且創建、更改．發佈的代價遠比HTML文本為小；同時wiki系統還支持面向社群的協作式寫作，為協作式寫作提供必要幫助；最後，wiki的寫作者自然構成了一個社群，wiki系統為這個社群提供簡單的交流工具。與其它超文本系統相比，wiki有使用方便及開放的特點，所以wiki系統可以幫助我們在一個社群內共用某領域的知識。
1995年Ward Cunningham為了方便模式社群的交流建立了一個工具——波特蘭模式知識庫(Portland Pattern Repository)。在建立這個系統的過程中，Ward Cunningham創造了Wiki的概念和名稱，並且實現了支持這些概念的服務系統。這個系統是最早的wiki系統。從1996年至2000年間，波特蘭模式知識庫圍繞著面向社群的協作式寫作，不斷發展出一些支持這種寫作的輔助工具，從而使wiki的概念不斷得到豐富。同時wiki的概念也得到了傳播，出現了許多類似的網站和軟體系統。
毫無疑問,你完全可以用wiki(工具)架設你的blog站點但是從比較嚴格的意義上來說,blog和Wiki是完全不同的東西,服務的目的就不同
簡單來說,blog是一種無主題變奏,一般來說是少數人(太多數情況下是一個人)關註的蔓延；一般的blog站點都會有一個主題,但這個主旨往往都是很鬆散，而且一般不會去刻意控制內容的相關性，blog日註重的是個人的思想（不管多麼不成熟，多麼地匪夷所思)，個性化是blog的最重要特色。blog註重交流，一般是小範圍的交流，通過訪問者對一些或者一篇blog文章的評論和交互；blog也有協作的意思，怛是協作一般是指多人維護，而維護者之間可能著力於完全不同的內容。這種協作在內容而言是比較鬆散的。任何人，任何主體的站點，你都可以以blog方式展示，都有它的生機和活力。
Wiki則不同。
Wiki站點一般都有著一個嚴格的共同關註點，Wikl的主體一般是明確和堅定的。Wiki站點的內容要求著高度相關性。其確定的主旨，任何寫作者和參與者都應當嚴肅地遵從。Wiki的協作是針對同一主題作外延式和內涵式的擴展,將同一個問題諼得很充分很深入。Wiki非常適合於做一種All about something“的站點。個性化在這裡不是最重要的，信息的完整性和充分性以及權威性才是真正的目標。Wiki由於其技術實現和含義的交織和複雜性，如果你漫無主固地去發揮，最終連建立者自己都會很快的迷失。Wiki使用最多也最合適的就是去共同進行文檔的寫作或者文章/書籍的寫作，特別是技術相關的（尤以程式開發相關的)FAQ，更台適以wiki來展現。
