運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見

威豆兄問我「如果有一個公司希望你來參與，建立 Open Source 的軟體工程流程 你願意試試看嗎 ?」，我很誠實地回答，我不適合這工作。但威豆兄是位有心人，對 Open Source 的發展很有熱情，又說道：

我們不是要理論的人啊 ... 我們要組成能夠去實踐的團隊 !! 看到很多中小學已經有很多老師願意投入 OSS 程式開發， 但到現在還是非常沒有組織 ... 照這樣下去， OSS 永遠是 Just for Fun !! 如何成為具有關鍵性的角色呢 ? 我們期待更多有心人投入 ... by 威豆 at 2007年02月1日

於是，我也很認真的寫了這篇文章，談談我心目中的 FOSS (Free/Open Source Software) 實踐團隊，以及我是如何從經驗中擁抱軟體工程 (主要是 XP/Agile) 的。

實務先於理論

我長期修改各種 FOSS (我不敢說參與，我總是這個改一些、那個改一些) ，每改一種總是很認真地去摸索作者的思緒與世界觀。在這過程中，很自然地模仿學習了一些作法。後來看了 XP/Agile 的書後才發現，原來我學到的那些作法就是 XP/Agile 的內容。因此，我一向認為「實務先於理論」，只要經驗累積到一定程度，舉手投足皆合理論。

訊息比組識重要

我不重視正式組織。對於人的協同作業，我以為訊息溝通比組織更重要。透過多元的訊息溝通網絡所連繫起來的組織，比正式的、行政結構的團隊組織更有效率與彈性。此一觀點，既是我的實務經驗，也是基於我的學識理論。在經濟學中，市場機制就是一個管道極為多元性的訊息溝通網絡組織。市場機制足以協同十幾億人作業，而任何正式組織都做不到這一點。

理論說完，來點實務。參與 FOSS 的人如何實踐訊息溝通網絡組織呢？

其實建立 FOSS 的訊息溝通網絡組織中最基本也最容易被忽視的第一步，就是使用版本控制工具 (Version control tools)。版本控制工具和訊息溝通有什麼關係？很不直覺，但卻是事實 (Programming with Subversion Quickstart) 。

以 CVS/SVN 這類工具為例，它傳遞與通知訊息的功能其實比電子郵件更有效率。 SVN 的固定動作是 Update → accept change → Commit → add/modify/revert → Update (repeat) 。往往我在 Update 時，就可以透過其他人在 Commit 時留下的訊息，了解到專案的進程或待辦事項。而它比 E-Mail 還有效率的一點在於， E-Mail 必須要知道「誰需要收到這些訊息」，才能把訊息發送給「那些人」。但在 Open Source 的世界中，「那些人」實在很難掌握。但是會使用版本控制工具取得專案內容的人，必定是關心這些訊息、需要這些訊息的人，訊息也就會透過版本控制發送給「那些人」 。藉由版本控制工具，我們不必知道彼此的存在，卻依然可以互相溝通訊息。

第二步，建立 Mailing list ，有些內容，例如公告事項、重大更新，甚至是主要工作負責人交接等非程式性事項，還是需要用 Mailing list 的方式發佈與通知。

第三步，建立 wiki 系統，主要用於建立文件、手冊。這也是訊息溝通的一環。一本好的文件與手冊，最重要的內容就在於功能的概要說明 (Overview) ，這比那種 step by step 的步驟說明更易於讓使用者掌握軟體的操作概念。對開發者也一樣重要，沒有比透過功能概要說明更快掌握軟體世界觀的途徑了。當一位參與者增加某個新功能時，就可以把功能概要編修到 wiki 上，不需要細目條列各函數說明。其他參與者透過 wiki 就能理解先前開發者的理念與思維，接著就能照著走。

TDD 的作用

說到這裡，其實 SourceForge.net 等 FOSS 專案服務商就已經提供了整套工具了。起步不難。除了工具的使用。欲建立基於訊息溝通網絡的 FOSS 專案組織還有一些流程方法。最重要的應該是 Test-Driven Develpment 。大多數時候 (大約九成機會) ，我是藉由觀看測試案例碼才了解這個軟體單元如何使用。我說的測試案例碼，並不一定要是一般文字文件，絕大多數是指 xUnit 格式的測試案例程式碼 (See also: 先說故事再動手設計, 從一個簡單故事看 Test Driven Development)。也不一定要 xUnit 格式的測試案例程式碼，甚至傳統的測試碼形式也可以。

#include <stdio.h>
#include <stdlib.h>
#include "pair.h"
#include "hash.h"

Pair* pair_create(const char* key, const void* value);

Hash* hash_create();
Hash* hash_add(Hash* hash, const Pair* item);
Pair* hash_get(const char*key);

#if defined(TEST)
void main() {
    Hash* map = hash_create();
    char* key = 'A10203';
    Pair* element = pair_create(key, 'john smith');
    hash_add(map, element);
    Pair* x = hash_get(key);
    printf("%s: %s\n", pair_key(x), pair_value(x));

    Pair_i* y = x;
    printf("%s: %s\n", (*y->key)(y), (*yx->value)(y));
}
#endif

上例是我以前寫 C 語言時的習慣。每實作一個功能模組，就會在底下用巨集 #if defined(TEST) ... #endif 包住測試程式碼。那個時候 (西元2000年以前) ，我還不知道什麼叫 Test-Driven Development ，而 XP/Agile 這兩個名詞根本還沒出現。但這種傳統方式，不也是一種 TDD 嗎？這些測試程式碼之所以重要，除了保障軟體品質外，就因這些測試程式碼可說是一個軟體單元的最佳使用範例。

在訊息溝通網絡組織中，溝通管道非常多元化。在軟體開發環境中，訊息更是無所不在，甚至使每一種軟體工具都能做為訊息溝通管道。像版本控制工具、 xUnit 工具等，其實都不是傳統上的訊息溝通工具，但它們確實發揮了訊息溝通的功能。我想到 XP/Agile 方法中重視溝通，以人為本的精神。這也是從此一實務經驗中得到的啟發。

軟體工程流程的實踐是從經驗中累積出來、從敗招中悟出來的。那些所謂「理論」其實只是系統性的論述整理。我迅速擁抱 XP/Agile 的原因，只是因為我在它們出現以前就已經這樣做事了；而我會這樣做的原因，又只是因為我長年依著個體導向技術概念在編程，自然而然就這樣做了 (See also: 敏捷編程 (Agile programming) 介紹文件@developerWorks 及個人感想)。別想太困難，有些時候會突然發覺：「原來我已經在這麼做了嘛」。 Just do it, you can make it.

相關文章

• 敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming