筆者在 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 等測試框架，成為自動測試流程的一環。

用故事測試作為「表達需求」和「驗證需求」的共通語言，這種做法的好處一言難盡。它不但大幅節省了溝通成本，也讓我們能每個月對系統進行一次改版時，不用擔心已經修復的瑕疵會再次出現。

最後，我們針對 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!

唐鳳

>>> 返回首頁