敏捷史話(十七):維基(Wiki)背後的靈感來源—— Ward Cunningham

在軟件開發領域,Ward Cunningham 有許多獨到的見解與成就。

1949年,Ward Cunningham 出生於印第安納州的密歇根市,並在萊克縣的一個小鎮中長大。懷揣着對計算機濃厚的興趣,在普渡大學學習期間,他獲得了跨學科工程(電子工程和計算機科學)學士學位以及計算機科學碩士學位。1978年,Ward Cunningham 完成了全部學業。

(普渡大學校徽)

畢業後的 Ward Cunningham 先後擔任過研發總監、首席工程師等職位,也自己創辦了 Cunningham&Cunningham,Inc.——專門從事面向對象編程的諮詢公司,以及一個面向軟件開發人員的教育性非盈利組織:The Hillside Group。

在自己豐富的軟件開發實踐的基礎上,Ward 總結出了很多經驗以及獨到的思想,這些思想也成爲日後軟件開發人員進行開發實踐的準則。

 

Cunningham 定律與 Wiki

 

Ward Cunningham 認爲:“在互聯網上獲得正確答案的最佳方法不是提出問題,而是發佈錯誤的答案。”這就是 Cunningham 定律,指人們更正錯誤的答案比回答問題更快。在日後的工作中,Cunningham 也在一直貫徹這一想法。

20世紀80年代末,Cunningham 在使用一個名爲 HyperCard 的程序時,發現了這樣一個問題:雖然 HyperCard 程序管理了許多稱爲“卡片”的資料,每張卡片都可劃分字段、上傳圖片,且支持修改編輯。這個類似網頁的程序對當時的人們來說很有用,但要想創建卡片與卡片之間的鏈接,就非常難了。

爲了解決這個問題,他在原有程序的基礎上增添了一個新的鏈接功能。用戶只需將鏈接輸入卡片上的一個特殊字段,原有每一字段的按鈕便會引導用戶去新的目標卡片。鏈接功能加上 HyperCard 卡片的應用,能夠讓用戶更正卡片上的錯誤內容,並鏈接到正確的卡片上。

這個在 HyperCard 的程序上寫出的小功能,就是 Ward Cunningham 對 Wiki 的最初構想。

1995年,Ward Cunningham 正式推出了第一個 Wiki 網站:WikiWikiWeb,方便程序員們進行思想交流。

關於爲什麼要創建 Wiki 這一問題,Cunningham 有話要說:“起初創建 Wiki,我的目的就是創建一個能夠將彼此經驗聯繫起來的環境,從而發現編程的模式語言。”這個想法在他看來稀鬆平常。以至於後來接受採訪時,被問及是否考慮過爲 Wiki 的概念申請專利,Cunningham 解釋說:“這個想法聽起來就像是沒人願意爲之付費的東西。”

儘管 Ward Cunningham 不考慮爲 Wiki 申請專利,但這並不表明他放棄了 Wiki。自Wiki 誕生之後,他就一直希望在全世界範圍內推廣 Wiki。

2001年,Cunningham 與他人合著了一本名爲《The Wiki Way》的書,書中主要介紹瞭如何安裝、創建並管理 Wiki 系統。2011年,他又啓動了 Smallest Federated Wiki 項目——用於 Wiki 聯合的軟件平臺,他爲 Wiki 添加了源代碼控制系統,以及其他軟件開發工具中的分叉功能……

至今,Ward Cunningham 仍在致力於推廣 Wiki 技術。

 

Cunningham 與面向對象編程

 

作爲一名程序員,Ward Cunningham 幾乎對所有的編程模式都有所涉獵,包括面向對象和敏捷建模。

他支持面向對象編程中長期關注代碼設計的實踐,更偏向於注重代碼和人的關係。爲了推動模式語言的運用,Cunningham 發佈了一個新的網站:模式共享社區,希望將不同作者的軟件模式集中在一起,展示現有模式之間的關係,以鼓勵用戶貢獻更多的模式,獲得更好的軟件。

 

Cunningham 與極限編程

 

在創建 Wiki 的前幾個月,Ward Cunningham、Kent Beck 一直與堅持軟件工程的教條主義者們爭論,爭論的內容主要在於是否實踐代碼集體所有權。

Cunningham 認爲,“代碼集體所有權有很大的好處,不僅能夠降低風險,還可以提升開發效率……”而教條主義者們認爲,“這簡直太荒謬了!實行代碼集體所有權後,你永遠不會有責任。如果你沒有責任,你永遠不會有質量。唯一能讓你負起責任的方法就是承擔責任。如果你不想再讓人寫出 Bug,你就必須把這個責任放在他的身上……”雙方並沒有說服彼此,但這場爭論讓 Cunningham 更堅定了維護代碼集體所有權的信念。

在設計 Wiki 的時候,Cunningham 認爲 Wiki 也應該實現在大型代碼庫中協作的過程。例如,你在一堆代碼中發現了一個問題,並且知道這個問題的解決方案。但是當你想去解決這個問題的時候,必須同這些代碼作者們去溝通、協商,這是一個非常困難且麻煩的過程。而實現代碼集體所有,實際上就會大大地減少溝通的成本。

因此,Wiki 中應用了代碼集體所有權的理念。Wiki “開放”的特點決定了當內容不完整或者出現錯誤的時候,所有人都可以用他們認爲合適的方式加以編輯。在 Wiki 中,所有參與者都對此負責

 

Cunningham 與《敏捷宣言》

 

我寧願轉向下一個想法,也不願爲保持最後一個想法的純正而奮鬥。”

敏捷真正帶給軟件的是一種能力,通過使團隊中的成員達成共同的目標,實現高質量的產品交付。“當《敏捷宣言》的四個價值觀被整齊地列在黑板上時,我們只是在感慨,雖然我們是十七個不同的個體,但寫在黑板上的內容是我們共同想要表達的東西。”回憶起2001年的雪鳥會議,Cunningham 這樣說。

而對於“稀釋”,也就是新想法的注入,他認爲,這一行業是在不斷髮展的,如果不能不停地嘗試用多種方法去做事情,就不再會有新的創造力。因此,作爲一名極限編程的狂熱愛好者,Cunningham 極力支持將敏捷與極限編程的工程實踐結合使用。

不論是 Wiki、面向對象編程、極限編程還是《敏捷宣言》,對於這些新的嘗試,Ward Cunningham 選擇迎難而上。對此,他也有自己的一套看法:“如果你想要做的好,那就想辦法每天都去做。選擇你害怕的事情,而不是選擇你擅長的事情,然後克服它,這就是推動我前行的動力。”

 

往期《敏捷史話》系列

敏捷史話(十六):我對《敏捷宣言》沒有半點貢獻—— Brian Marick

敏捷史話(十五):我發明了敏捷估算撲克牌 —— James Greening

敏捷史話(十四):敏捷之峯的攀登者 —— Jim Highsmith

敏捷史話(十三):我被 Facebook 解僱了——Kent Beck

敏捷史話(十二):你現在接觸的敏捷也許是“黑暗敏捷”——Ron Jeffries

敏捷史話(十一):敏捷宣言“間諜”——Steve Mellor

敏捷史話(十):我犧牲了滑雪時間,參加了一場軟件革命——Jon Kern

敏捷史話(九):用做麪包的方式做敏捷——Alistair Cockburn

敏捷史話(八):敏捷的破局之道——Martin Fowler

敏捷史話(七):從程序員、作家到搖滾樂手——Andy Hunt的多面人生

敏捷史話(六):也許這個人能拯救你的代碼 —— Robert C. Martin

敏捷史話(五):敏捷已逝 —— Dave Thomas

敏捷史話(四):敏捷是人的天性 —— Arie van Bennekum

敏捷史話(三):篤定前行的勇者——Ken Schwaber

敏捷史話(二):Scrum社區的悲劇性損失——Mike Beedle

敏捷史話(一):用一半的時間做兩倍的事——Jeff Sutherland

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章