評估 Ruby

如果您正在閱讀這篇文章，我假設您知道 Ruby 程式語言已經引起廣泛討論，特別是 Rails 這個用於開發網路應用的架構。有些人認為它是程式設計的未來，而另一些人則認為它是一個危險的岔路。

我在幾年前開始使用 Ruby。實用主義讓我產生興趣，它很快成為我偏好的指令碼語言。隨著時間的推移，它逐漸處理了這個網站的大部分製作工作，特別是這個部落格。我非常喜歡這門語言。

我個人喜好和它是否應該被我們的客戶使用之間存在著差距。我們可以根據它的功能評估它是否適合客戶專案，這會引發許多關於動態類型、慣例優於組態、程序與執行緒等優缺點的爭論。這樣的討論很有用，但我仍然對它們保持謹慎。有太多事情很難用這種方式判斷，因此我們在客戶專案上花費大量時間被在高爾夫球場上聽起來不錯的技術拖慢進度。我比較喜歡根據經驗做出這個判斷，找到在主流環境中具有交付記錄並且嘗試使用 Ruby 的人。

有些內容可以在公開的作者身上看到。Ruby 吸引了許多在其他地方擁有良好經驗但認為 Ruby 能為他們帶來額外優勢的人，像是 both、Prags、Justin Gehtland、Bruce Tate 等人，這些名字就足以讓 Ruby 值得一看。但我可能有點狹隘，我一直在密切注意 ThoughtWorkers：我了解他們的歷史，而且可以更輕鬆地查看他們的專案。

現在還很早，但我現在已經有許多專案經驗可以參考。到目前為止，結果都堅定地支持 Ruby。當我問「你認為你在 Ruby 中的生產力是否比在 Java/C# 中高出許多」時，每次我都會得到一個強烈的「是」。這對我來說已經足夠開始說，對於一個合適的專案，你應該讓 Ruby 轉一圈。當然，這只留下了一個小問題，什麼才算是「合適」。

需要提的一件事是，儘管我們有幾個可以稱為典型網路專案的專案，這些專案很符合目前所討論的 Rails 主要領域，但也有不同的元素。

• 一個消費者直接操作觸控螢幕的資訊亭裝置。Rails 在這裡出現，因為 UI 是非常 Ajax 的網路前端。但也有與硬體裝置、加密、奇怪的網路事務的通訊——所有這些都在類似 Linux 盒子的應用程式上。
• 在批次處理中進行大量的 SQL 處理，其中 Ruby 用來指定需要什麼，而產生的 Ruby 表達式會轉換成 SQL 來執行實際的工作。前端有一點 Rails 的影子——但這也不是典型的 Rails 應用程式。
• 一個在許多方面看起來像標準網路應用程式的專案，但涉及從不同格式整理大量資料，以及一些非常精美的圖形和圖表（使用 Ploticus）。

在所有這些情況中，參與者表示，他們獲得的功能和價值比在其他平台上更快。這對我來說表示，如果你正在尋找傳遞速度和生產力，你應該認真考慮 Ruby。

仍然有一些開放性的問題。特別是，現在還太早，無法看出在後續的增強階段會發生什麼，特別是在團隊變動時。有些人認為 Ruby 的動態特性和缺乏工具會是一個問題，另一些人則認為 Ruby 鼓勵的簡潔性會彌補差異。這是一個我們目前還無法真正回答的問題的本質——我會在找到更多資訊時更新給你。

Cedric Beust 有效地主張，即使 Ruby 是優越的平台，它也可能不會成為主流。我當然理解這個論點，就像許多前 Smalltalk 使用者一樣，我早就知道比目前主流企業選擇更具生產力的平台。如果你認為只使用主流平台很重要，你需要等待更長的時間才能看到會發生什麼。當然，有很多人 不在乎追隨主流。

還有許多專案的開發生產力被政治和其他溝通因素淹沒。在這裡，Ruby 的優勢會顯著減弱。

但整體而言，這些來自值得信賴的同事的經驗，表示我越來越樂觀地使用 Ruby 來進行需要速度、回應能力和生產力的嚴肅工作。