筆者在 2009 年 6 月時加入 SocialCalc 專案團隊。經過四個月的密集作業,我們在 10 月 19 日(VisiCalc 的 30 周年紀念日)發表了 SocialCalc 1.0 版。
從 WikiCalc 到 SocialCalc,中間經歷了三年的開發。相形之下,最後這四個月只是一段短暫的時間。儘管如此,這段和 Socialtext 同事在 Dan Bricklin 的指導下進行協作的過程,仍使我獲益匪淺。在此,筆者想將那段時間學到的經驗分享給大家。
願景清晰的首席設計師非常重要
在《設計的設計(The Design of Design)》一書中,Fred Brooks 認為,在建構複雜系統時,若能專注於清晰連貫的設計概念,而非各自為政的想法,那麼溝通成本將會大幅下降。
依 Brooks 的想法,這種連貫式設計概念的構想,最好能由一個人來主導:
概念的完整性是偉大設計中最重要的特性。由於完整的概念只能出自一人或 少數人的合作構想,因此明智的管理者會大膽委託才華出眾的首席設計師, 來承擔整個設計任務。
對於 SocialCalc 這個專案來說,讓 Tracy Ruggles 擔任首席用戶體驗設計師,是讓我們成功實現原初構想的關鍵。由於 SocialCalc 的底層引擎十分易於擴展,因此各種新功能的想法往往層出不窮;Tracy 透過草圖進行原型設計的才能,為我們提供了巨大的幫助,讓我們能用最直觀的方式呈現出所有的功能。
共筆確保專案延續
在我加入專案之前,SocialCalc 已有超過兩年的設計和開發歷史,但我卻能在幾天之內立刻趕上進度,開始作出貢獻。
這是因為「所有資訊都在共筆裡」– 從早期的設計草稿到最新的瀏覽器支援清單,整個流程都詳細記載在共筆頁面和 SocialCalc 試算表裡。
通過閱讀該專案的相關記錄,讓我能跳過新成員加入時常見的上手期,快速跟上目前的進度。
這在傳統的開源專案比較少見。傳統專案中大部分的交流都是在 IRC 和郵件列表中進行的,而共筆(如果有使用的話)往往只用來存放相關資源的記錄和鏈結 – 如果有新人加入,要想通過結構混亂的 IRC 紀錄和郵件存檔追趕進度,無疑會更加困難。
善加運用時區差異
Ruby on Rails 的發明人 David Heinemeier Hansson 在加入 37signals 時,曾這樣評價分散式團隊的優勢:
哥本哈根和芝加哥之間相隔的七個時區,實際上減少了我們受到的打擾, 讓我們做出更多工作。
在 SocialCalc 的研發過程中,對於台北和帕羅奧圖之間相隔的九個時區,我們亦有同感。
通常我們會在一天 24 小時內,完成一次「設計-開發-品管」反饋循環,每個環節用到某個人的八小時。這種非同步式的協作,促使我們運用能自我描述的完整作品(設計草圖、代碼,以及測試)來溝通,從而大幅增進相互之間的信任。
樂趣最優
筆者在 2006 年於 CONISLI 會議上所作的主題演講「-OFun:樂趣最優(Optimizing for Fun)」裡,將自己領導分散式團隊開發 Perl 6 語言的經驗,總結為幾個重點。其中「隨時保持藍圖清晰」、「寬恕 > 許可」、「打破僵局」、「不求共識,只求創意」,以及「使用代碼描述概念」這幾項,特別適合小型的分散式團隊。
因此,在開發 SocialCalc 時,我們特別重視團隊成員間的知識分享,以確保每個人都不會成為主要瓶頸。
另外,當設計過程出現多種備選方案時,我們會主動將每個方案都進行實做,以深入探勘它們的設計空間,並先一步解決可能出現的衝突。如果在此過程裡發現有更好的設計,我們也不怕將整個原型打掉重寫。
雖然缺乏面對面交流,但這些文化特質幫我們培養相互之間的信任和情誼,並將爭議降到最低,讓 SocialCalc 的開發成為一件樂事。
通過故事測試推動開發工作
在加入 Socialtext 前,我曾倡導「將測試寫進規格裡」的方法,這一點在 Perl 6 語言規格 中就能看到:我們逐段幫規格加上測試,並持續確保兩者之間的同步。
然而 SocialCalc 專案品管團隊的成員 Ken Pier 和 Matt Heusser 卻讓我大開眼界 – 原來這種做法還可以更進一步,將測試提昇到「可以執行的規格」這個境界。
在《美妙的測試(Beautiful Testing)》一書第 16 章,「剝開 Socialtext 的玻璃洋蔥」裡,Matt 用如下方式解釋了我們由「故事測試」推動的開發流程:
工作的最基本單元是一系列「故事」,也就是一系列非常輕量級的需求文件。 每個故事只包含對一個功能的簡要描述,以及此功能的運作實例,用最直白的 文句進行描述。我們稱這些實例為「接納度測試」。 在故事形成初期,設計師會先寫出初步的接納度測試,隨後由開發人員和測試 人員進行討論,之後開發人員才開始編寫代碼。
隨後這些故事測試會被轉換為「共筆測試(wikitests)」。這是一種基於表格的語言,脫胎自 Ward Cunningham 的 FIT 框架。用此語言寫成的測試存進共筆系統後,會自動連接到 Test::WWW::Mechanize 和 Test::WWW::Selenium 等測試框架,成為自動測試流程的一環。
用故事測試作為「表達需求」和「驗證需求」的共通語言,這種做法的好處一言難盡。它不但大幅節省了溝通成本,也讓我們能每個月對系統進行一次改版時,不用擔心已經修復的瑕疵會再次出現。
CPAL 開源授權
最後,我們針對 SocialCalc 而設計的開源授權,也令我們受益匪淺。
Socialtext 為了 SocialCalc,設計出通用公共授權(Common Public Attribution License)。CPAL 以 Mozilla 公共授權為基礎,並讓原作者可以要求在軟體的界面上顯示自己的標誌。CPAL 還加上了「網絡使用條款」,讓衍生作品在透過網路提供服務時,也授予一般使用者取得源碼的權利。
在獲得開放源碼促進會和自由軟體基金會的認可後,已經有不少知名網站(例如 Facebook 和 Reddit)選擇用 CPAL 方式發布自己的平台源碼,這對我們無疑是莫大的鼓勵。
因為 CPAL 屬於「較弱型著佐權(weak copyleft)」授權,因此開發人員可以將它整合進任何自由軟體或私有軟體裡,只需要分享出針對 SocialCalc 本身的修改。這讓各個社群都可以採用 SocialCalc ,並對其進行改進。
底下是一些以 SocialCalc 為基礎的開源專案:
- Drupal 的 Sheetnode 專案,及其自行維護的 SocialCalc 分支。
- Luke Closs 發起的 OLPC/XOCOM 平台移植版。
- SEETA 的 OLPC/Sugar 平台移植版,由 Luke 的版本衍生而來。
- SEETA 的 Palm Pre 平台移植版。
- Ramu Ramamurthy 的 Scala/Java 試算表伺服器專案。
本章中的範例,包括豐富文本和協作編輯等功能,都能在 http://github.com/audreyt/socialcalc 下載。WikiCalc 1.0 代碼的歷史存檔,則可由http://github.com/audreyt/wikicalc 取得。
開源的網頁試算表引擎,有許多有趣的應用可能。如果您能將 SocialCalc 嵌入到您自己的專案中,這絕對是我們喜聞樂見的。
Happy Hacking!
唐鳳
Recent Comments