我曾撰寫的文章《從Java到Ruby：所有管理者需要知道的事情》并非是為程序開發(fā)者所寫，而是寫給技術(shù)選用的決策者看的。在理解Ruby難點以及使用Rails框架方面，Ruby擁護者們?yōu)閯偲鸩降拈_發(fā)者做出了大量值得稱贊的工作，但是對于管理者和執(zhí)行人員來說，并沒有足夠的信息幫助他們在眾多技術(shù)之間做出選擇。在這個系列的上一篇文章中，我們探討了在Java在線商店中建立向?qū)ы椖康牟呗浴Ｔ谶@篇文章中，我們將要探討Java與Ruby語言遷移時風(fēng)險預(yù)測方面的問題。

通常來說，“使用Ruby具有風(fēng)險”是一種普遍的看法，這存在一定的原因。因為使用新的語言天生是有風(fēng)險的。隨著Ruby on Rails逐步進入到主流的開發(fā)領(lǐng)域中，這樣的風(fēng)險將會隨時間逐漸降低，因為有逐步增長的開發(fā)者群、組件（或稱作gems和plug-ins）相關(guān)的書籍、以及業(yè)務(wù)合作伙伴與你溝通交流。但同時你也可以聽到主流的觀點指出“使用Java是安全的”。對于這種的觀點，我持有強烈的反對意見。隨著語言的膨脹，這樣的風(fēng)險通常也會增長。為了便于理解在目前在這些觀點上正發(fā)生什么變化，投入點精力去研究Java最初的應(yīng)用情況是值得的。

新技術(shù)采用概況

許多分析家擁有技術(shù)應(yīng)用所需的描述模型。其中最為流行的模型是定義在Ruby的Web開發(fā)框架Iowa中，用來描述農(nóng)產(chǎn)品的應(yīng)用，稍后在一本由Geoffrey A. Moore寫作的名為《跨越鴻溝》（Crossing the Chasm）的書中，被用來描述技術(shù)內(nèi)容。在書中，Moore分析了技術(shù)應(yīng)用周期中存在著的五個截然不同的群體：

  • 技術(shù)專家。這個群體傾向于采用新的技術(shù)。任何一種有前途的技術(shù)都會引起這個群體的注意。
  • 先行采納者。不管這項技術(shù)是否在主流技術(shù)中取得成功，這個群體都將會采用新的技術(shù)來提升競爭優(yōu)勢。
  • 實用主義者。一旦新的技術(shù)進入主流應(yīng)用，或是有足夠陡峭的增長曲線來保證技術(shù)將得到廣泛采用，那么實用主義者就會積極采用新的技術(shù)。
  • 保守派。只有新技術(shù)成為必須的時候，他們才會考慮采用新的技術(shù)。
  • 懷疑論者。這個群體可能很晚才會采用新的技術(shù)，或者也可能永遠只使用某一特定技術(shù)。

Moore指出，技術(shù)應(yīng)用的關(guān)鍵之處在于團隊中是否存在實用主義者。因為實用主義者需要新技術(shù)大規(guī)模的應(yīng)用，這個中間群體希望看到其他務(wù)實派在團隊做出承諾之前就使用新的技術(shù)。這是一個類似于《第二十二條軍規(guī)》書中所描述的現(xiàn)象，因為務(wù)實派們都會相互依賴的存在。出于這樣的原因，在先行采納者排列在技術(shù)專家之后和務(wù)實派之前，你會經(jīng)常在市場接受度曲線中看到一種下降的趨勢。Moore將這種下降稱之為鴻溝傾向，并且這種想法應(yīng)出于圍繞任何新技術(shù)的風(fēng)險討論的中心。

Moore解決方法是，把重點放在跨越鴻溝的過程中。通常來說，你很難通過一個巨大的飛躍跨過鴻溝。你需要有一個目標明確的細分市場。Java技術(shù)首先通過Applet程序進入網(wǎng)絡(luò)客戶端，之后轉(zhuǎn)向服務(wù)端的計算、移動終端、以及其他類似于移動計算以及企業(yè)架構(gòu)的應(yīng)用，最終為網(wǎng)絡(luò)帶來強大沖擊。

在《超越Java》一書中，我認為存在于程序設(shè)計語言之間的鴻溝特別嚴重。我們大多數(shù)人都認識到在Lisp語言上投入精力將大幅提高生產(chǎn)率，但是同時也會導(dǎo)致更難找到合適的程序開發(fā)人員、教學(xué)資源、類庫以及組件等。同時我們還將不得不付出更多的花費來進行一些必要的整合工作。出于這個原因，大眾市場只會以大約每十年的時間周期更換主流的編程語言。在服務(wù)端編程語言方面，可以清晰看到這種趨勢的存在。COBOL和Fortran語言出現(xiàn)于1954年到1961年之間。C語言則誕生在上世紀70年代初期，C++是出現(xiàn)在上世紀80年代中期，Java語言則出現(xiàn)在1996年。我應(yīng)當(dāng)把C#語言算做整合高效的Java語言克隆版本，雖然這樣的說法可能會引發(fā)一些爭辯。許多其他的語言在此階段中誕生，但是上述語言仍舊沒有一個能夠占據(jù)統(tǒng)治地位。伴隨的風(fēng)險是阻礙新編程語言被廣泛采用的最重要原因。

Java的風(fēng)險概況

使用Java語言曾經(jīng)需要克服很大的風(fēng)險。當(dāng)時，大多數(shù)服務(wù)端的編程都在使用C++語言。C++是一門高效的操作系統(tǒng)語言，非常適用于應(yīng)用程序開發(fā)。C語言家族在這方面的表現(xiàn)相當(dāng)出色，因為客戶機/服務(wù)器端編程以及用戶界面開發(fā)需要程序性能與適應(yīng)性良好地結(jié)合在一起，在當(dāng)時其他的編程語言都無法符合這樣的要求。為了克服伴隨采用新編程語言而來的風(fēng)險，Java需要以下的三個條件均成立：

  • C++開發(fā)者不得不經(jīng)歷一番辛苦的學(xué)習(xí)過程。指針的存在（由于缺少編譯時的安全性）導(dǎo)致各種各樣難以消除的缺陷。內(nèi)存管理使得內(nèi)存泄漏成為家常便飯。C++對于大多數(shù)程序開發(fā)者來說，顯得過于復(fù)雜。這些問題增加了針對于C++語言的風(fēng)險評估。
  • Java需要解決一些C++語言無法處理的工作。Java語言所具有簡潔、靈活的特性以及眾多C++所不包括的類庫支持。這些要素減少了針對于Java語言的風(fēng)險評估，并可以保持開發(fā)團隊小型化最終從根本上提高生產(chǎn)力。
  • Java需要一個催化劑。隨著網(wǎng)絡(luò)爆炸，Applet應(yīng)用普遍被嵌入在NetScape瀏覽器中，使得C語言開發(fā)者不得不轉(zhuǎn)向去開始使用Java語言。C++因為和Java語法的類似，可以簡單地進行過渡。Java得以迅速獲得數(shù)量龐大的用戶群，并且在同微軟的競爭中逐步提升這樣的過渡。

Java的膨脹要比我們以前所見的任何一次技術(shù)浪潮都要迅速，同時也可能比我一生所見的任何技術(shù)都要龐大，然而Java的發(fā)展藍圖卻一直保持清晰。為了建立新的語言，原有的語言已不適應(yīng)開發(fā)者的需求，新的語言必須要克服原有語言的缺陷，并最終以某些催化效應(yīng)迅速聚集起數(shù)量龐大的用戶群。

Java作為Internet應(yīng)用語言在客戶端迅速得到立足。借助于靈巧的Applet應(yīng)用程序，由于Java提供了對于應(yīng)用開發(fā)者極有幫助的特性，使得Java快速轉(zhuǎn)移到服務(wù)器端開發(fā)，這些特性包含有：

  • 內(nèi)存管理
  • 干凈的繼承模型
  • 更好的面向?qū)ο蠊δ?
  • 便攜性
  • Internet類庫
  • 安全

……以及其他許多特性。在我看來，Java一直以來都是最為成功的編程語言。隨著Java不斷的改進，使用Java語言變得越來越安全，并最終在Internet應(yīng)用中統(tǒng)領(lǐng)著服務(wù)端開發(fā)的市場。商業(yè)投資，開發(fā)者社區(qū)，各種教育培訓(xùn)，開放源代碼的框架，以及各種各樣的信息發(fā)布都使得使用Java開發(fā)的風(fēng)險降低。上述幾點清晰地解釋了Java取得成功的原因。

一旦新的程序開發(fā)語言跨越鴻溝，開發(fā)語言相關(guān)的風(fēng)險則會隨著市場占有率的提升顯著減少。

Java則擁有一個令人贊嘆的成功過程。但是程序設(shè)計語言沒有仍舊停留在不確定的技術(shù)發(fā)展水平之上。所有成功語言都會產(chǎn)生技術(shù)膨脹，因為它們必須去適應(yīng)使用者不斷變化的需求。成功的編程語言無法像其他的語言一樣快速的適應(yīng)變化，他們必須保持一定程度上的向后兼容，來滿足逐步增長的用戶基本需求。隨著技術(shù)滯后與語言膨脹的產(chǎn)生，另一種形式的風(fēng)險預(yù)測逐步形成。為了新的風(fēng)險預(yù)測，由于風(fēng)險與程序開發(fā)者高效完成工作的能力相關(guān)，使得風(fēng)險與市場占有率的降低有必然的聯(lián)系。

到目前為止，我已經(jīng)開始關(guān)注于新生技術(shù)的市場風(fēng)險。在Java誕生十周年之際，另一種形式的風(fēng)險評估成為必須。就像《人月神話》、《死亡之旅》和《人件》等許多有影響力的書籍中鼓吹的那些風(fēng)險一樣：

  • 低下的生產(chǎn)力將導(dǎo)致更龐大的團隊規(guī)模和更長的時間周期
  • 風(fēng)險隨著項目的規(guī)模而增加
  • 風(fēng)險隨著團隊規(guī)模的擴張而增加
  • 質(zhì)量風(fēng)險，以Bug的數(shù)量來衡量，隨著代碼行數(shù)的增加而增長
  • 成本的增長導(dǎo)致風(fēng)險的增加
  • 綜合成本隨著復(fù)雜性的提高而增加

隨著程序設(shè)計語言或者編程范例的使用有了積累，相對于技術(shù)發(fā)展水平，語言將會與生產(chǎn)力相關(guān)聯(lián)。項目團隊需要增加規(guī)模，開發(fā)者需要編寫更多的代碼來解決相同的問題。所有這些因素本身就會增加風(fēng)險。所有的因素將會導(dǎo)致必然的結(jié)論。

由于市場主宰地位的終止，相對于技術(shù)發(fā)展水平來說，生產(chǎn)力風(fēng)險與開發(fā)語言相關(guān)性將會增加。

在Java語言的范疇中，這些情況是否以及如何發(fā)生是一個將會引起激烈爭論的話題。當(dāng)然，Java仍然是解決整個一系列企業(yè)問題的最佳語言，比方說非常大型的項目，或是比如雙相提交或核心對象關(guān)系映射等具備特定需求的問題。針對于Java的商業(yè)投資從來沒有這么強過，并且Java社區(qū)一直是保持持續(xù)高漲。但是根基中的缺陷逐漸開始顯現(xiàn)出來。

Java的企業(yè)級JavaBean框架，WS-*風(fēng)格的網(wǎng)絡(luò)服務(wù)，以及JavaEE的復(fù)雜性和寬松度已受到越來越多的批評。James Duncan Davidson，servlet的創(chuàng)始人之一，曾表示Java不再像從前那樣方便易用。目前很難給一個普通的Java開發(fā)者，講明白如何解決最一般的編程問題：比如有后臺數(shù)據(jù)庫支撐的網(wǎng)絡(luò)應(yīng)用。出現(xiàn)的相關(guān)證據(jù)是，已經(jīng)出現(xiàn)了很多使用其他語言的開發(fā)框架，最為出名的就是Ruby on Rails，在處理小規(guī)模問題時具備極高的生產(chǎn)力。資深Java開發(fā)者James Duncan Davidson，Mike Clark，Justin Gehtland，Stuart Halloway以及其他許多開發(fā)者都證明，在關(guān)鍵的小型項目中使用了Rails之后，獲得了非常高的生產(chǎn)效率：具備后臺數(shù)據(jù)庫支撐的綠色網(wǎng)絡(luò)應(yīng)用。當(dāng)然，我的個人經(jīng)驗也是可以輕松地使用Ruby on Rails構(gòu)造、部署并維護這樣的應(yīng)用。

這些報告將會引起廣泛的爭論，就像是早期關(guān)于Java生產(chǎn)力的那些報告一樣。還記得，在Java開發(fā)廣泛普及之前，Java首次出現(xiàn)在各式的小型應(yīng)用中。開發(fā)人員的生產(chǎn)力是驅(qū)動Java早先增長期的重要標準。請謹記Moore關(guān)于新技術(shù)出現(xiàn)的理論。跨越鴻溝最好的方式不是通過一次大的跳躍，而是每次只前進一個小的階段。

我堅信復(fù)雜性和松散的開發(fā)效率是使得Java目前正在經(jīng)歷風(fēng)險的原因。

Ruby與生俱來的風(fēng)險

比起其他新生的開發(fā)語言來，Ruby并沒有什么特別之處。缺少商業(yè)投資，有限的開發(fā)資源，還缺少開發(fā)經(jīng)驗，這都為新生的程序設(shè)計語言帶來了風(fēng)險。下面是一些我遭遇到的較大的風(fēng)險。

  • 人才的缺乏。很難找到熟練的Ruby開發(fā)人員。根據(jù)Java的發(fā)展情況來看，這樣的現(xiàn)狀將會很快有所改觀，但是就目前來說，如果你計劃在很短的時間內(nèi)組織一個人數(shù)較多的Ruby開發(fā)團隊，其困難程度遠比組建相同的Java團隊要大得多。
  • 缺少經(jīng)驗。許多LAMP相關(guān)的語言已經(jīng)建立了記錄跟蹤機制。Google使用Python；許多主流的.COM公司使用Perl或C語言。目前仍沒有使用Ruby打造的旗艦級應(yīng)用，來展示Ruby語言強健的可拓展性，或是復(fù)雜的企業(yè)級集成。我們只是不知道Ruby是否可以解決某些特定類型的問題。
  • 部署和配置策略。Ruby on Rails已經(jīng)出現(xiàn)將近一年的時間，所以在部署和配置方面的經(jīng)驗還不如競爭語言那樣豐富。
  • 缺少類庫支持。Ruby遠不如Java語言擁有這么多豐富的類庫支持。
  • 缺少商業(yè)投資。你需要花費很大的力氣才能找到Ruby的咨詢、培訓(xùn)或承包的機會，并且這些大多數(shù)還并不存在。

還有其他許多類似的風(fēng)險。然而，你可以有效地降低使用Ruby語言的風(fēng)險，比如采取績效掛鉤的風(fēng)險預(yù)測。雖然開發(fā)和部署大型Ruby應(yīng)用的相關(guān)知識積累仍然十分有限，但是你可以在適當(dāng)?shù)闹埸c不斷學(xué)習(xí)新的知識。對于PHP、Perl和Python等LAMP相關(guān)語言，業(yè)界有著非常豐富的知識積累。在應(yīng)用部署機制、Web服務(wù)器以及非共享可拓展策略等方面都是一致的。

在考慮參與開發(fā)的人手時，不要低估你通過對員工進行內(nèi)部培訓(xùn)來建立高效團隊的能力。對于使用Spring、Eclipse、Hibernate和WebWork進行Java開發(fā)的新手，我的訓(xùn)練計劃常常是為Ruby on Rails開發(fā)者指定培訓(xùn)計劃的五倍。如果你開始使用具有類似于Ruby特性的開發(fā)語言，比方說Perl，Python或Smalltalk，它們可以幫助你很好地起步。如果你打算從零開始培養(yǎng)一個程序員的話，培養(yǎng)一個使用Ruby的開發(fā)者，遠比培訓(xùn)Java開發(fā)者使用最新的一大堆各種框架要合算的多。

想一想那些眾多的函數(shù)類庫，有多少是你真正需要的？如果你需要分布式處理，雙相提交，那么就使用Java編程。如果您需要與Microsoft Office的宏完美地整合，那么就使用.NET。但如果你想編寫操作系統(tǒng)整合腳本，或編寫基于數(shù)據(jù)庫的綠色Web應(yīng)用，那么Ruby則正是你所需要的。并且你可以經(jīng)常編寫要用到但手邊沒有的任何程序。我曾協(xié)助一家公司工作，他們在兩個星期內(nèi)編寫了自己的數(shù)據(jù)庫驅(qū)動程序，但仍然比完成項目其他工作所用的時間要多。我還認識一個使用Ruby在四小時內(nèi)修補現(xiàn)有代碼，為程序拓展Oracle支持的開發(fā)者。Thoughtworks在很短的開發(fā)周期內(nèi)就發(fā)布了RBatis，即Ruby版本的實體關(guān)系映射工具iBATIS。

所以當(dāng)你站在全局考慮時，會感覺到使用Ruby的風(fēng)險往往被夸大了，尤其是在Java并沒有帶給你一切所需資源的時候。自己真正去嘗試使用Ruby語言，是把這些風(fēng)險納入控制范圍之內(nèi)的最好方法。使用Rails開發(fā)一些實際的應(yīng)用，并站在實踐的角度上發(fā)言。而不要盲目迷信別人的說法。

神話 vs 事實

Rails是銀彈。

人們曾經(jīng)在Rails項目上失敗過，并且還將會有更多失敗的教訓(xùn)。如果你在沒有具備必須技能的情況下使用它，你也將可能面臨失敗的命運。

與之類似的說明是，如果Java語言不是導(dǎo)致失敗的問題根源，那么Ruby將同樣不會是你的答案。大多數(shù)軟件開發(fā)問題的出現(xiàn)是與特定技術(shù)無關(guān)的。如果你正在遭受打擊，Ruby on Rails的采用只能加快你遭受打擊的速度。

選擇Ruby頗具風(fēng)險，因為你無法預(yù)測到錯誤。

采用任何新的語言，最主要的風(fēng)險是你將預(yù)測到錯誤，并且錯誤停滯在使用的類庫之中。這的確是一項相當(dāng)重大的風(fēng)險，但是這個問題決不僅局限于Ruby語言之中。在Java語言里，你需要就主要類庫的使用做出決定，其中任何一個都可能帶給你復(fù)雜臃腫的代碼。你是否會為聲明事物選擇Spring或EJB 3等技術(shù)？Java的持久層架構(gòu)是不是一個正確的選擇，或者Hibernate就是最終的解決方案？關(guān)于Web MVC分層的正確選擇是什么，是逐步衰落的Struts框架，還是其他更易用的框架？

在Ruby語言之中，選擇Web開發(fā)框架則相對簡單許多。你將很可能與Rails一起工作。語言動態(tài)的特性同樣各層之間的結(jié)構(gòu)更為簡化，通過特定的約定來使得開發(fā)配置比Java實現(xiàn)更為明晰。

為Java項目招募人手總是更為容易。

Java擁有數(shù)量龐大的開發(fā)者群體，但是開發(fā)社區(qū)之間有著巨大的分歧。如果你想使用一個綜合的Java工具集，你的選擇是十分有限的。即使你選擇了像Spring這樣的流行框架，你的團隊必須還要學(xué)會使用針對給定項目所需的各種類庫。在這種情況下，Java的核心力量，過多的函數(shù)類庫，將會給項目帶來副作用。相反，大部分的Ruby開發(fā)者都知道Rails框架。此外，你通常需要更多的Java開發(fā)者去處理類似的任務(wù)。有時，招募Java的開發(fā)人員要容易得多。但有時，情況也并不是這樣。

Rails無法拓展。

Ruby on Rails其實有很好的延展性。它的緩存模型非常強大，并且非共享的架構(gòu)在LAMP社區(qū)中多次被證明是非常有效的。實際上，我們知道Ruby on Rails完全可以適應(yīng)較大型應(yīng)用的要求。我們不知道Ruby on Rails是否可以承受大規(guī)模的應(yīng)用部署。沒有固有的架構(gòu)使我相信這是一條死胡同。對于典型的應(yīng)用，總之錯誤的潛伏期是存在于數(shù)據(jù)庫端。

Rails的整合選項十分有限。

Rails對于基于ReST的Web服務(wù)有著良好的支持。Ruby同樣通過JRuby項目提供對于JVM的支持，以及提供對于微軟的CLR運行時的支持。同時Ruby也提供了良好的消息傳輸支持。最后，為項目選擇最好的工具將會幫助你始終處于良好的狀態(tài)。優(yōu)秀的開發(fā)團隊可以在Java和Ruby項目上同時獲得成功。

總結(jié)：你可以承擔(dān)什么樣的角色？

如果你正在考慮使用Ruby，那么在你身邊將會有很多有用的信息。與其他同時在有效使用Java和Ruby的開發(fā)者交流。閱讀關(guān)于開發(fā)框架的資料。查找從Java到Ruby的遷移資料。如果你并不想放棄Java，只是想尋找輕量級的開發(fā)體驗，那么去了解一下那些可以為你帶來更多相關(guān)體驗的項目，比如說RIFE、JMatter或Wicket項目。如果你認為Ruby可能是一個好的選擇，那么要留心以下的建議：

  • 為項目選擇合適的工具。Ruby on Rails并不是銀彈，ROR是一個針對以數(shù)據(jù)庫為后臺的高度精簡的Web應(yīng)用開發(fā)環(huán)境。與新的數(shù)據(jù)庫模式配合較好，或者你可以通過變更來適應(yīng)Rails的各種固有優(yōu)點。
  • 細心計劃開發(fā)團隊的熱身階段。你不需要在Monster.com站點投放廣告并在三日之內(nèi)為項目招募齊全開發(fā)人員。但你可能需要考慮培訓(xùn)你部分或全部的開發(fā)者，并且招募幾個頂尖的Rails開發(fā)者，或是請求某些項目咨詢來幫助你把項目啟動。
  • 了解你使用傳統(tǒng)方式的結(jié)合點。通常，項目中最頭疼的部分是定義與外部系統(tǒng)的交互。你最初證明概念的工作需要與某些接觸點交互，至少是要明確你在何處對項目感覺到滿意。

如果你還是不確定，那么做一個先行者，或是遵從保守派的觀點。緩解風(fēng)險最佳的方法總是優(yōu)秀的判斷能力。

關(guān)于作者

Bruce Tate居住在德克薩斯州的奧斯丁，是一位山地自行車和橡皮艇愛好者，同時也是兩個孩子的父親。Bruce已經(jīng)撰寫了9本編程方面的書籍，其中包含兩本Ruby的書籍以及五本Java相關(guān)的書籍。Bruce還是RapidRed公司的創(chuàng)始人，公司專注于包含Ruby和Rails在內(nèi)的輕量級開發(fā)技術(shù)，并提供開發(fā)、資訊和培訓(xùn)等業(yè)務(wù)。Bruce是一位世界范圍內(nèi)廣受稱贊的優(yōu)秀演說家、程序員、培訓(xùn)師以及技術(shù)顧問。

查看英文原文：From Java to Ruby: Risk