tech-sjh

2009年1月20日 星期二

程式設計的文藝復興

翻譯自:AppTrain: Renaissance Programming

這是一個關於採用 Ruby on Rails, PHP, MATLAB, 以及 Google
Docs 程式設計介面的故事。

文藝復興時期的程式設計師應該可以跨越平台、程式語言的限制寫
出產品所需要的程式。猶如文藝復興時期的建築師般,程式設計師
知道設計寫作程式的重點,就是在於產出程式的整齊、對稱與簡潔


當我們在實作 kpozsports 產品時,第一個挑戰就是原始網站是用
PHP寫的。在過去幾年來我都是在 Ruby, Rails 的程式設計開發環
境。我們團隊中的 Jim 是一位優秀的 PHP 程式設計師。我們要如
何在同一個網站中讓 PHP 跟 Ruby 共存?

1) 釐清責任區分
專案計劃中每位開發者都要達成特定的功能目標。完成這些功能性
目標的程式語言只是輔助工具。即使是一家小公司,使用多種工具
完成目標也是很常見的。比如 Rob 是 MATLAB 專家,所有運算集
中的程式碼都是使用 MATLAB 完成。架構網頁前端的程式語言則
是 PHP。這方面我們交給 Jim 完成。Ruby 在整個計劃中則是隨處
可見的,因為他的高藕合特性幾乎可以運用在任何需要系統整合的
專案中。我的主要責任是從多個來源蒐集資料,組織好資料後再傳
送到有 MATLAB 後端運算的 PHP 網站上。

2) 聚集類似的目標與工作任務(內聚)
軟體開發稱這個動作為內聚 cohesion. 本專案中的 Rake 任務是到
網頁上蒐集公開的網頁資料,所需要找的是同一款電玩遊戲的所
有相關網頁資料。剛好我最近都在研究相關的議題,這正好在工
作中派上用場。

3) 保持元件獨立
在專案中我們除了前端 PHP 及其相關的 MATLAB 模組,也架構
另一個 Rails 內部網站,兩個網站雖然互相溝通但實作上相互獨立
,我們稱為 low coupling, 如此一來我們兩邊元件開發可以同時進
行而不造成相互等待的時間浪費,也不會產生過於複雜的溝通系
統。

4) 共同設計
建構一個可用的軟體應用程式需要持續的設計。專案中所有成員
都共同參與設計的工作。我們會把重要的觀念放到線上領域知識
字典,並隨著設計過程增加到網站上。這讓我們對同樣的概念有
相同的詞彙,增加溝通效率。保有共同詞彙讓我們在開發程式的
命名上也更有共識,最後呈現給使用者的介面也會更一致。

5) 不要重造車輪
Don't Repeat Yourself, DRY 原則。The Pragmatic Programmer
裡面寫著:

在同一系統內,每個知識必須要有單一、明確、權威的表示方式。

當資料在資料庫之間傳遞時,必須由具權威代表的資料庫傳遞到備
份資料庫中。我們系統中的權威資料庫是存放在 Rails 框架構成的
網站,所有在 Rails 對資料庫做的修改都會連帶修改其他的備份資
料庫中。固定資料傳遞的方向是為了避免網站架構變得太複雜難以
維護。除了在程式碼中保持 DRY 原則外,整個系統架構上都要記
得同樣的 DRY 原則。

6) 持續的溝通
沒有位在同一辦公室的共同開發者,更是需要積極主動的溝通。在
這個專案中我們每週有兩次共同電話會議。在一星期的開始我們會
討論計劃、策略、戰術,以及任務、與遇到的問題。一星期結束時
則是每個人各自簡報的會議。如此就算有人太忙碌,或是在旅行中
,也都至少可以參與到一次的每週會議。我們私底下也是會常常溝
通,從討論複雜的程式設計議題,到補修統計學,或是共同慶祝喜
愛的橄欖球隊獲勝。

7) 開放的心胸
Pragmatic Thinking and Learning 中,Andy Hunt 討論到
神經生成科學 Neurogenesis。與一般坊間聽到的剛好相反,我們的
腦細胞在進入成年以後仍然不斷地產出與生長。在這個專案中我們
接觸到越多陌生的開發環境與工具,就讓我們心智成長、心靈更加
開放。

當 Rob 需要網路上的橄欖球統計資料時,我們利用 Rake 進行這項
工作,並將資料送到 Google Spreadsheet API。另一個 Rake 針對
連結到這個 Spreadsheet 的 PHP 網頁進行更新連結到新
Spreadsheet。

我們系統中已經整合許多不同系統與環境,如果要再新增其他系統
也是輕而易舉。注意我前面提到的這些工具,都是專案成員共同開
發,因此我們同時也都在不同的開發環境中一起成長精進。

在開發網站時,我也會考慮都用 Rails 或是 PHP 進行開發比較好?
結果發現將每個工具用在他最適切的使用需求上才是最好的做法
這讓我想到文藝復興時代的藝術建築創作,一個熟練多種不同開發
環境與工具的程式設計師。就我個人來說也彷彿經歷一場文藝復興
時期的成長,除了使用的工具與開發環境外,最重要的是產出的軟
體是否符合需求?

相關文章:

C++ 之父 Bjarne Stroustrup 談軟體教育

相關連結:

Renaissance Programming

沒有留言:

張貼留言

版權宣告、免責聲明


創用 CC 授權條款
本著作係採用創用 CC 姓名標示-非商業性-相同方式分享 4.0 國際 授權條款授權.
免責聲明: 本文所載資料僅供參考,並不構成投資建議,
讀者閱讀或使用該資料所導致結果需要自擔風險與責任,
作者概不承擔閱讀人行為之任何風險與責任。
除非有特別宣稱,作者言論並不代表所屬任何團體、公司、或其他人意見。