author Bruce Tate
我曾撰寫的文章《從Java到Ruby：所有管理者需要知道的事情》並非是爲程序開發者所寫，而是寫給技術選用的決策者看的。在理解Ruby難點以及使用Rails框架方面，Ruby擁護者們爲剛起步的開發者做出了大量值得稱讚的工作，但是對於管理者和執行人員來說，並沒有足夠的信息幫助他們在衆多技術之間做出選擇。在這個系列的上一篇文章中，我們探討了在Java在線商店中建立嚮導項目的策略。在這篇文章中，我們將要探討Java與Ruby語言遷移時風險預測方面的問題。
通常來說，“使用Ruby具有風險”是一種普遍的看法，這存在一定的原因。因爲使用新的語言天生是有風險的。隨着Ruby on Rails逐步進入到主流的開發領域中，這樣的風險將會隨時間逐漸降低，因爲有逐步增長的開發者羣、組件（或稱作gems和plug-ins）相關的書籍、以及業務合作伙伴與你溝通交流。但同時你也可以聽到主流的觀點指出“使用Java是安全的”。對於這種的觀點，我持有強烈的反對意見。隨着語言的膨脹，這樣的風險通常也會增長。爲了便於理解在目前在這些觀點上正發生什麼變化，投入點精力去研究Java最初的應用情況是值得的。
新技術採用概況
許多分析家擁有技術應用所需的描述模型。其中最爲流行的模型是定義在Ruby的Web開發框架Iowa中，用來描述農產品的應用，稍後在一本由Geoffrey A. Moore寫作的名爲《跨越鴻溝》（Crossing the Chasm）的書中，被用來描述技術內容。在書中，Moore分析了技術應用週期中存在着的五個截然不同的羣體：
- 技術專家。這個羣體傾向於採用新的技術。任何一種有前途的技術都會引起這個羣體的注意。
- 先行採納者。不管這項技術是否在主流技術中取得成功，這個羣體都將會採用新的技術來提升競爭優勢。
- 實用主義者。一旦新的技術進入主流應用，或是有足夠陡峭的增長曲線來保證技術將得到廣泛採用，那麼實用主義者就會積極採用新的技術。
- 保守派。只有新技術成爲必須的時候，他們纔會考慮採用新的技術。
- 懷疑論者。這個羣體可能很晚纔會採用新的技術，或者也可能永遠只使用某一特定技術。
Moore指出，技術應用的關鍵之處在於團隊中是否存在實用主義者。因爲實用主義者需要新技術大規模的應用，這個中間羣體希望看到其他務實派在團隊做出承諾之前就使用新的技術。這是一個類似於《第二十二條軍規》書中所描述的現象，因爲務實派們都會相互依賴的存在。出於這樣的原因，在先行採納者排列在技術專家之後和務實派之前，你會經常在市場接受度曲線中看到一種下降的趨勢。Moore將這種下降稱之爲鴻溝傾向，並且這種想法應出於圍繞任何新技術的風險討論的中心。
Moore解決方法是，把重點放在跨越鴻溝的過程中。通常來說，你很難通過一個巨大的飛躍跨過鴻溝。你需要有一個目標明確的細分市場。Java技術首先通過Applet程序進入網絡客戶端，之後轉向服務端的計算、移動終端、以及其他類似於移動計算以及企業架構的應用，最終爲網絡帶來強大沖擊。
在《超越Java》一書中，我認爲存在於程序設計語言之間的鴻溝特別嚴重。我們大多數人都認識到在Lisp語言上投入精力將大幅提高生產率，但是同時也會導致更難找到合適的程序開發人員、教學資源、類庫以及組件等。同時我們還將不得不付出更多的花費來進行一些必要的整合工作。出於這個原因，大衆市場只會以大約每十年的時間週期更換主流的編程語言。在服務端編程語言方面，可以清晰看到這種趨勢的存在。COBOL和Fortran語言出現於1954年到1961年之間。C語言則誕生在上世紀70年代初期，C++是出現在上世紀80年代中期，Java語言則出現在1996年。我應當把C#語言算做整合高效的Java語言克隆版本，雖然這樣的說法可能會引發一些爭辯。許多其他的語言在此階段中誕生，但是上述語言仍舊沒有一個能夠佔據統治地位。伴隨的風險是阻礙新編程語言被廣泛採用的最重要原因。
Java的風險概況
使用Java語言曾經需要克服很大的風險。當時，大多數服務端的編程都在使用C++語言。C++是一門高效的操作系統語言，非常適用於應用程序開發。C語言家族在這方面的表現相當出色，因爲客戶機/服務器端編程以及用戶界面開發需要程序性能與適應性良好地結合在一起，在當時其他的編程語言都無法符合這樣的要求。爲了克服伴隨採用新編程語言而來的風險，Java需要以下的三個條件均成立：
- C++開發者不得不經歷一番辛苦的學習過程。指針的存在（由於缺少編譯時的安全性）導致各種各樣難以消除的缺陷。內存管理使得內存泄漏成爲家常便飯。C++對於大多數程序開發者來說，顯得過於複雜。這些問題增加了針對於C++語言的風險評估。
- Java需要解決一些C++語言無法處理的工作。Java語言所具有簡潔、靈活的特性以及衆多C++所不包括的類庫支持。這些要素減少了針對於Java語言的風險評估，並可以保持開發團隊小型化最終從根本上提高生產力。
- Java需要一個催化劑。隨着網絡爆炸，Applet應用普遍被嵌入在NetScape瀏覽器中，使得C語言開發者不得不轉向去開始使用Java語言。C++因爲和Java語法的類似，可以簡單地進行過渡。Java得以迅速獲得數量龐大的用戶羣，並且在同微軟的競爭中逐步提升這樣的過渡。
Java的膨脹要比我們以前所見的任何一次技術浪潮都要迅速，同時也可能比我一生所見的任何技術都要龐大，然而Java的發展藍圖卻一直保持清晰。爲了建立新的語言，原有的語言已不適應開發者的需求，新的語言必須要克服原有語言的缺陷，並最終以某些催化效應迅速聚集起數量龐大的用戶羣。
Java作爲Internet應用語言在客戶端迅速得到立足。藉助於靈巧的Applet應用程序，由於Java提供了對於應用開發者極有幫助的特性，使得Java快速轉移到服務器端開發，這些特性包含有：
- 內存管理
- 乾淨的繼承模型
- 更好的面向對象功能
- 便攜性
- Internet類庫
- 安全
……以及其他許多特性。在我看來，Java一直以來都是最爲成功的編程語言。隨着Java不斷的改進，使用Java語言變得越來越安全，並最終在Internet應用中統領着服務端開發的市場。商業投資，開發者社區，各種教育培訓，開放源代碼的框架，以及各種各樣的信息發佈都使得使用Java開發的風險降低。上述幾點清晰地解釋了Java取得成功的原因。
一旦新的程序開發語言跨越鴻溝，開發語言相關的風險則會隨着市場佔有率的提升顯著減少。
Java則擁有一個令人讚歎的成功過程。但是程序設計語言沒有仍舊停留在不確定的技術發展水平之上。所有成功語言都會產生技術膨脹，因爲它們必須去適應使用者不斷變化的需求。成功的編程語言無法像其他的語言一樣快速的適應變化，他們必須保持一定程度上的向後兼容，來滿足逐步增長的用戶基本需求。隨着技術滯後與語言膨脹的產生，另一種形式的風險預測逐步形成。爲了新的風險預測，由於風險與程序開發者高效完成工作的能力相關，使得風險與市場佔有率的降低有必然的聯繫。
到目前爲止，我已經開始關注於新生技術的市場風險。在Java誕生十週年之際，另一種形式的風險評估成爲必須。就像《人月神話》、《死亡之旅》和《人件》等許多有影響力的書籍中鼓吹的那些風險一樣：
- 低下的生產力將導致更龐大的團隊規模和更長的時間週期
- 風險隨着項目的規模而增加
- 風險隨着團隊規模的擴張而增加
- 質量風險，以Bug的數量來衡量，隨着代碼行數的增加而增長
- 成本的增長導致風險的增加
- 綜合成本隨着複雜性的提高而增加
隨着程序設計語言或者編程範例的使用有了積累，相對於技術發展水平，語言將會與生產力相關聯。項目團隊需要增加規模，開發者需要編寫更多的代碼來解決相同的問題。所有這些因素本身就會增加風險。所有的因素將會導致必然的結論。
由於市場主宰地位的終止，相對於技術發展水平來說，生產力風險與開發語言相關性將會增加。
在Java語言的範疇中，這些情況是否以及如何發生是一個將會引起激烈爭論的話題。當然，Java仍然是解決整個一系列企業問題的最佳語言，比方說非常大型的項目，或是比如雙相提交或核心對象關係映射等具備特定需求的問題。針對於Java的商業投資從來沒有這麼強過，並且Java社區一直是保持持續高漲。但是根基中的缺陷逐漸開始顯現出來。
Java的企業級JavaBean框架，WS-*風格的網絡服務，以及JavaEE的複雜性和寬鬆度已受到越來越多的批評。James Duncan Davidson，servlet的創始人之一，曾表示Java不再像從前那樣方便易用。目前很難給一個普通的Java開發者，講明白如何解決最一般的編程問題：比如有後臺數據庫支撐的網絡應用。出現的相關證據是，已經出現了很多使用其他語言的開發框架，最爲出名的就是Ruby on Rails，在處理小規模問題時具備極高的生產力。資深Java開發者James Duncan Davidson，Mike Clark，Justin Gehtland，Stuart Halloway以及其他許多開發者都證明，在關鍵的小型項目中使用了Rails之後，獲得了非常高的生產效率：具備後臺數據庫支撐的綠色網絡應用。當然，我的個人經驗也是可以輕鬆地使用Ruby on Rails構造、部署並維護這樣的應用。
這些報告將會引起廣泛的爭論，就像是早期關於Java生產力的那些報告一樣。還記得，在Java開發廣泛普及之前，Java首次出現在各式的小型應用中。開發人員的生產力是驅動Java早先增長期的重要標準。請謹記Moore關於新技術出現的理論。跨越鴻溝最好的方式不是通過一次大的跳躍，而是每次只前進一個小的階段。
我堅信複雜性和鬆散的開發效率是使得Java目前正在經歷風險的原因。
Ruby與生俱來的風險
比起其他新生的開發語言來，Ruby並沒有什麼特別之處。缺少商業投資，有限的開發資源，還缺少開發經驗，這都爲新生的程序設計語言帶來了風險。下面是一些我遭遇到的較大的風險。
- 人才的缺乏。很難找到熟練的Ruby開發人員。根據Java的發展情況來看，這樣的現狀將會很快有所改觀，但是就目前來說，如果你計劃在很短的時間內組織一個人數較多的Ruby開發團隊，其困難程度遠比組建相同的Java團隊要大得多。
- 缺少經驗。許多LAMP相關的語言已經建立了記錄跟蹤機制。Google使用Python；許多主流的.COM公司使用Perl或C語言。目前仍沒有使用Ruby打造的旗艦級應用，來展示Ruby語言強健的可拓展性，或是複雜的企業級集成。我們只是不知道Ruby是否可以解決某些特定類型的問題。
- 部署和配置策略。Ruby on Rails已經出現將近一年的時間，所以在部署和配置方面的經驗還不如競爭語言那樣豐富。
- 缺少類庫支持。Ruby遠不如Java語言擁有這麼多豐富的類庫支持。
- 缺少商業投資。你需要花費很大的力氣才能找到Ruby的諮詢、培訓或承包的機會，並且這些大多數還並不存在。
還有其他許多類似的風險。然而，你可以有效地降低使用Ruby語言的風險，比如採取績效掛鉤的風險預測。雖然開發和部署大型Ruby應用的相關知識積累仍然十分有限，但是你可以在適當的着眼點不斷學習新的知識。對於PHP、Perl和Python等LAMP相關語言，業界有着非常豐富的知識積累。在應用部署機制、Web服務器以及非共享可拓展策略等方面都是一致的。
在考慮參與開發的人手時，不要低估你通過對員工進行內部培訓來建立高效團隊的能力。對於使用Spring、Eclipse、Hibernate和WebWork進行Java開發的新手，我的訓練計劃常常是爲Ruby on Rails開發者指定培訓計劃的五倍。如果你開始使用具有類似於Ruby特性的開發語言，比方說Perl，Python或Smalltalk，它們可以幫助你很好地起步。如果你打算從零開始培養一個程序員的話，培養一個使用Ruby的開發者，遠比培訓Java開發者使用最新的一大堆各種框架要合算的多。
想一想那些衆多的函數類庫，有多少是你真正需要的？如果你需要分佈式處理，雙相提交，那麼就使用Java編程。如果您需要與Microsoft Office的宏完美地整合，那麼就使用.NET。但如果你想編寫操作系統整合腳本，或編寫基於數據庫的綠色Web應用，那麼Ruby則正是你所需要的。並且你可以經常編寫要用到但手邊沒有的任何程序。我曾協助一家公司工作，他們在兩個星期內編寫了自己的數據庫驅動程序，但仍然比完成項目其他工作所用的時間要多。我還認識一個使用Ruby在四小時內修補現有代碼，爲程序拓展Oracle支持的開發者。Thoughtworks在很短的開發週期內就發佈了RBatis，即Ruby版本的實體關係映射工具iBATIS。
所以當你站在全局考慮時，會感覺到使用Ruby的風險往往被誇大了，尤其是在Java並沒有帶給你一切所需資源的時候。自己真正去嘗試使用Ruby語言，是把這些風險納入控制範圍之內的最好方法。使用Rails開發一些實際的應用，並站在實踐的角度上發言。而不要盲目迷信別人的說法。
神話 vs 事實
Rails是銀彈。
人們曾經在Rails項目上失敗過，並且還將會有更多失敗的教訓。如果你在沒有具備必須技能的情況下使用它，你也將可能面臨失敗的命運。
與之類似的說明是，如果Java語言不是導致失敗的問題根源，那麼Ruby將同樣不會是你的答案。大多數軟件開發問題的出現是與特定技術無關的。如果你正在遭受打擊，Ruby on Rails的採用只能加快你遭受打擊的速度。
選擇Ruby頗具風險，因爲你無法預測到錯誤。
採用任何新的語言，最主要的風險是你將預測到錯誤，並且錯誤停滯在使用的類庫之中。這的確是一項相當重大的風險，但是這個問題決不僅侷限於Ruby語言之中。在Java語言裏，你需要就主要類庫的使用做出決定，其中任何一個都可能帶給你複雜臃腫的代碼。你是否會爲聲明事物選擇Spring或EJB 3等技術？Java的持久層架構是不是一個正確的選擇，或者Hibernate就是最終的解決方案？關於Web MVC分層的正確選擇是什麼，是逐步衰落的Struts框架，還是其他更易用的框架？
在Ruby語言之中，選擇Web開發框架則相對簡單許多。你將很可能與Rails一起工作。語言動態的特性同樣各層之間的結構更爲簡化，通過特定的約定來使得開發配置比Java實現更爲明晰。
爲Java項目招募人手總是更爲容易。
Java擁有數量龐大的開發者羣體，但是開發社區之間有着巨大的分歧。如果你想使用一個綜合的Java工具集，你的選擇是十分有限的。即使你選擇了像Spring這樣的流行框架，你的團隊必須還要學會使用針對給定項目所需的各種類庫。在這種情況下，Java的核心力量，過多的函數類庫，將會給項目帶來副作用。相反，大部分的Ruby開發者都知道Rails框架。此外，你通常需要更多的Java開發者去處理類似的任務。有時，招募Java的開發人員要容易得多。但有時，情況也並不是這樣。
Rails無法拓展。
Ruby on Rails其實有很好的延展性。它的緩存模型非常強大，並且非共享的架構在LAMP社區中多次被證明是非常有效的。實際上，我們知道Ruby on Rails完全可以適應較大型應用的要求。我們不知道Ruby on Rails是否可以承受大規模的應用部署。沒有固有的架構使我相信這是一條死衚衕。對於典型的應用，總之錯誤的潛伏期是存在於數據庫端。
Rails的整合選項十分有限。
Rails對於基於ReST的Web服務有着良好的支持。Ruby同樣通過JRuby項目提供對於JVM的支持，以及提供對於微軟的CLR運行時的支持。同時Ruby也提供了良好的消息傳輸支持。最後，爲項目選擇最好的工具將會幫助你始終處於良好的狀態。優秀的開發團隊可以在Java和Ruby項目上同時獲得成功。
總結：你可以承擔什麼樣的角色？
如果你正在考慮使用Ruby，那麼在你身邊將會有很多有用的信息。與其他同時在有效使用Java和Ruby的開發者交流。閱讀關於開發框架的資料。查找從Java到Ruby的遷移資料。如果你並不想放棄Java，只是想尋找輕量級的開發體驗，那麼去了解一下那些可以爲你帶來更多相關體驗的項目，比如說RIFE、JMatter或Wicket項目。如果你認爲Ruby可能是一個好的選擇，那麼要留心以下的建議：
- 爲項目選擇合適的工具。Ruby on Rails並不是銀彈，ROR是一個針對以數據庫爲後臺的高度精簡的Web應用開發環境。與新的數據庫模式配合較好，或者你可以通過變更來適應Rails的各種固有優點。
- 細心計劃開發團隊的熱身階段。你不需要在Monster.com站點投放廣告並在三日之內爲項目招募齊全開發人員。但你可能需要考慮培訓你部分或全部的開發者，並且招募幾個頂尖的Rails開發者，或是請求某些項目諮詢來幫助你把項目啓動。
- 瞭解你使用傳統方式的結合點。通常，項目中最頭疼的部分是定義與外部系統的交互。你最初證明概念的工作需要與某些接觸點交互，至少是要明確你在何處對項目感覺到滿意。
如果你還是不確定，那麼做一個先行者，或是遵從保守派的觀點。緩解風險最佳的方法總是優秀的判斷能力。
關於作者
Bruce Tate居住在德克薩斯州的奧斯丁，是一位山地自行車和橡皮艇愛好者，同時也是兩個孩子的父親。Bruce已經撰寫了9本編程方面的書籍，其中包含兩本Ruby的書籍以及五本Java相關的書籍。Bruce還是RapidRed公司的創始人，公司專注於包含Ruby和Rails在內的輕量級開發技術，並提供開發、資訊和培訓等業務。Bruce是一位世界範圍內廣受稱讚的優秀演說家、程序員、培訓師以及技術顧問。