最近更新: 2007-02-01

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

威豆兄問我「如果有一個公司希望你來參與,建立 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 就能理解先前開發者的理念與思維,接著就能照著走。

補充資料: GoogleCode 就為軟體專案提供了這三種支援,其中的 Google Group 即為 mailing-list。參閱《在 GoogleCode 建立軟體專案的第一步》了解如何申請與維護。

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.

相關文章
樂多舊網址: http://blog.roodo.com/rocksaying/archives/2687531.html

樂多舊回應
victor@ossii.com.tw(威豆) (#comment-3907279)
Fri, 02 Feb 2007 08:09:21 +0800
沒想到小小的回應換到如此棒的文章 !!

你說的這些是建立 OSS 專案,
現在不是專案的問題,是架構的問題,
專案的工具等等,偉大的 OSSF 已經都有了,
然而在台灣做 OSS 的情形又是如何呢 ?
最近對二句話很有感觸
『橫眉冷對千夫指,俯首甘為孺子牛』
每一個趕跳下來做 OSS 的人,我相信都敢於面對千夫指,
但『甘為孺子牛』的呢 ?
我期許自己開始忘掉千夫指,開始去做孺子牛 ...

你願意將這些觀念及使用技術傳授給想做 OSS 的人嗎 ?
( CVS / Mail-List / TDD ... )
未留名 (#comment-3911933)
Sat, 03 Feb 2007 12:19:27 +0800
做 OSS 要面對千夫所指?
嗯,我全無此感覺。

CVS / Mail-List / TDD 這些內容,皆在我的文章中,有空來看看就可以了。
未留名 (#comment-3912293)
Sat, 03 Feb 2007 16:02:17 +0800
>> 做 OSS 要面對千夫所指?
>> 嗯,我全無此感覺。

站的位置不同,感覺也不同。不過沒關系,求得放心就好。
無為也可以很有作為 ...

>> CVS / Mail-List / TDD 這些內容,皆在我的文章中,有空來看看就可以了。

也只好默默欣賞囉 !!
未留名 (#comment-4282289)
Wed, 28 Mar 2007 11:56:12 +0800
補充資料:
hoamon's 的 SVN 使用經驗「使用svn/cvs的重要觀念:人的溝通才能花解程式碼的衝突」提到:每次 commit 前,要先作 update ,且要看看別人所修改的程式碼及註解,如果與自己的程式發生嚴重的邏輯衝突時,不是硬幹別人的程式,而是打個電話跟他聊聊。

該文提到了一般人使用版本控制工具時並未建立應有的多人協同作業觀念,常忽視版本控制工具的溝通功能。