世上已存在不少自由軟體專案開發網站，除了 SourceForge.net、Tigris.org、GForge.org、Savannah 之外，Google 也推出類似的服務，並廣泛引起注目。不過，本文並不打算把焦點放在各網站的比較上，而是嘗試介紹這類網站的技術共通處，以及分享自己的經驗歷程。

讓我們姑且先以 forge 這字眼，來代表所有提供這類服務的網站。接著，看看 forge 有哪些主要的技術挑戰? 從小處來看，我們挑了兩個整合議題來談：「帳號身份及權限」與「搜尋引擎」；從大處來看，我們將介紹採用開發框架時，要留意的議題。

整合帳號身份及權限

專案開發網站以使用者及專案為起始，再配合「事務追蹤」「郵遞論壇」「討論區」「版本管理」等功能，交互關連出複雜的身份及權限對應關係。從 open source 世界，我們可以找到許多個別軟體提供這些功能，但它們也自成一格，使用各別的帳號權限表，帳號整合必須優先處理。

以最簡化的情境來當例子，一個專案在建立之際，會先有一位專案管理員，而管理員可以邀請新成員，在新成員加入後，就可以利用事務追蹤工具，來新增工作事項，並由管理員分派工作給合適的成員，而成員可以加入郵遞論壇，以電子信件與其他使用者進行討論。

在上述的例子，具備「管理員」身份的使用者，必須擁有「會員管理」功能權限，以便設定成員的功能狀態，並能夠方便執行「邀請新成員」動作；而郵遞論壇的管理政策，也常與使用者身份有關，例如，是否允許「非成員」加入討論，討論區是否採「審核制」等；關於版本管理，也要決定哪些成員具備 commit 權限。

這些功能，進一步還可能有著不同的工作流程 (workflow)。舉例來說，如果 post 的內容可以先存成草稿 (draft) 狀態，經作者提交 (submit) 給管理員確認 (review) 後發佈 (publish)，或是退回 (reject) 再改。因此，除了不同狀態 (status) 的設定，工作流程也包含動作 (action) 的設定，這些都需要緊密配合帳號身份及權限。

搜尋引擎

上述各項功能所產生的資料記錄，或多或少，都希望能結合搜尋引擎的服務，產生更具價值的資訊，例如找出「最新建立的 10 個專案」，「最近加入專案的 5 位成員」，「最常被使用的關鍵字詞」，如果所有的資料記錄都是「完整公開」，或是沒有專屬於某個專案或某位成員的話，那麼直接交給 Google 協助搜尋，倒也省事，偏偏事與願違，一個身份及權限複雜的網站，很容易牽涉專屬資料或處於未公開階段的文件，此時，採用自家專用的搜尋引擎，便成為必要的需求。

另外，對大型網站而言，索引 (index) 的建立方式，也考驗著網站開發者在系統效能及資訊即時度之間的取捨智慧，常見的索引類型包括「Date (Range) Index」「Field Index」「Keyword Index」「Path Index」「Text Index」等，中文資料衍生出斷詞的議題，然後再配合適當的 metadata 資料，以及排序方式，由搜尋結果的頁面呈現給使用者，當資料量過大時，還需要處理分批顯示的問題。

整合框架的考量

概括地看，forge 所處理的，就是「異質系統整合」議題。儘管可以站在 open source 的巨人肩膀上，但實務經驗告訴我們，爬上巨人肩膀絕不是輕鬆差事，而且我們會擔心爬錯肩膀，爬上爬下的成本必須納入考量，這也突顯選擇整合框架 (framework) 的重要性。

想把 Apache、Subversion、Mailing List、Tracker 整合起來? 談一下 OpenFoundry 的經驗吧。以前，我們利用 Request Tracker (RT) 這套 Perl 軟體，作為整個系統的主架構，將開發平台上的使用者對應到 RT 的使用者，將專案對應到 RT 的 Queue (表單)，並將使用者/專案關連到系統內部實作用的 Ticket (申請單) 上。這種對應關係，讓開發者可以對使用者與專案新增 Custom Field (自訂欄位)，且不用修改程式碼，同時也可以利用 RT 系統對 Ticket 物件所提供的功能，重複使用其新增/編輯/搜尋等程式碼。

上述的對應機制雖然提供了相當大的彈性，但是也因此承擔了許多包袱。Ticket / Custom Field 的設計，在對物件操作時，常對資料庫產生過多的 SQL 指令，且原 RT 的設計具有較嚴密的權限控管機制，在我們開放存取的站台上，也增加了許多不必要的檢查。這些問題在單一物件操作時較不明顯，但隨著網站的使用者與專案數日益增多，每一個操作都會將此問題放大。 當專案與使用者的大量成長後，系統將無法負荷。

Data, Logic and Presentation: 三者的適度封裝

我們發現，如果網站在設計時，沒有對專案/成員等概念進行封裝，且實作細節被散到展現層 (Presentation Layer) 的各處，就會導致修改展現層的頁面時，仍需瞭解專案的實作細節。這種情況，一方面會造成網站不易更新，另一方面也造成潛在新模組貢獻者的卻步，因為他們需要瞭解過多細節。

「資料」的備份及維護，必須和網站程式「邏輯」，以及外觀「呈現」，相互獨立，最好能納入測試個案 (Test Case) 的規畫，以免陷入以下的窘境：

1. 不知道有哪些程式/網頁依賴舊的實作細節，所以也不知道改成新的實作方式後，原先的功能是否仍能正常運作。
2. 就算知道新的方式可行，也有數百個地方需要做修改，形成如霰彈式修改 (Shotgun Surgery) 的問題。

小結

以上，我們簡介了 forge 主要的技術挑戰，不管是採用「教堂式」或「市集式」開發模式，大抵都脫離不了這些議題。而在 OpenFoundry 的未來開發上，讓它能主動走入既有的開發社群，是我們努力的方向。

歸功於 open source 的快速演化生態，新的技術與工具不斷竄起，例如 CSS、RSS、AJAX、Social Software 等，這些技術工具同時帶來契機與挑戰，讓我們思索如何讓網站系統能夠與時並進，並利用好的開發架構，方便社群開發力量投入協助，更快速地納入受歡迎的服務功能，同時間，把這些開發經驗分享給更多朋友，也是我們樂於回饋社群的小貢獻。

shrink this item