不過，到目前為止這還只是一場開發(fā)者領導的革命，要說服管理層則要令費一番口舌了。管理人員必須了解采用Ruby帶來的風險，讓主流語言（如Java）坐冷板凳所帶來的風險——哪怕僅對一個項目，還有Ruby語言能力的技術(shù)全貌。坦白說，目前這方面的文字很少。以《FromJavatoRuby》一書為基礎，這個系列的文章將在下面三個方面探索如何在保守的公司采用Ruby：試點項目（PilotProjects），了解風險，以及Java與Ruby的整合策略。
引路人之道
Ruby是一門優(yōu)秀的語言。倘若你想在一家保守的公司里為它樹立威望，那么請在正確的環(huán)境下使用它實現(xiàn)一個試點項目來解決正確的問題。剩下的工作讓Ruby完成就可以了。不過，為了建立你的試點項目，你首先需要創(chuàng)建一個案例，讓Ruby看起來足夠吸引眼球，從而讓大家甘心冒這個風險。接著，你得在你的試點策略里面添筋加骨。鑒于人們對采用一門新語言與生俱來的抵抗力，你要選擇一個不給疑慮留任何余地的方法。最終，你得愿意為成功建立制度根基。
因此，你的第一步就應當是樹立回報的價值，一個具備足夠說服力的效益，來克服采用新語言帶來的風險。有了Ruby，構(gòu)建你的案例要比你想象的容易得多。
找到一項有說服力的回報
在所有東西都說到而且做到了之后，你的核心優(yōu)勢就會在短期和長期的生產(chǎn)力上不斷表現(xiàn)噴涌而出。短期生產(chǎn)力即你可以迅速地構(gòu)建出一個應用。就像大部分的腳本語言一樣，Ruby在短期生產(chǎn)力上表現(xiàn)不凡。但是常見的腳本語言不同的是，早期的跡象表明，在較長期的問題上，例如易維護性，簡單性，擴展性等方面，Ruby同樣會表現(xiàn)得卓爾不群。
Ruby，還有它的旗艦級Rails框架，能帶來引人注目的生產(chǎn)力提升，對于某些應用程序來說常常能接近三到五倍。當你把生產(chǎn)力提高了之后，你就可以縮小團隊的規(guī)模、削減溝通的開銷，并消除額外的浪費了。同時，小型的開發(fā)團隊還可以提升敏捷開發(fā)過程的效率。這些改善所帶來的成倍影響常常沒有被人充分說明展現(xiàn)出來。
開發(fā)人員們對動態(tài)類型（DynamicTyping）、元編程（Metaprogramming）、領域特定語言（DomainSpecificLanguages），以及更豐富的抽象特性，如閉包（Closures）和Continuations等，所能帶來影響的了解是頗為深刻的。RubyonRails框架也還有一些革命性的特性還沒有在Java框架中被重現(xiàn)出來。對于Java開發(fā)人員來說，快速的反饋周期、內(nèi)建的測試功能、約定優(yōu)于配置（ConvertionoverConfiguration）和革命性的持久層框架都足以令人眼睛放光。然而，當你在和你的中層管理人員交談的時候，你不可能跟他們滔滔不絕地背誦完這些特性列表，然后開始期待你的論據(jù)就是一針見血的。你必須從生產(chǎn)力的角度來表述這些特性。
更長期的優(yōu)勢也是存在的。削減的配置、驚人的簡易程度、更少的代碼行數(shù)，還有領域特定語言，這一切都使得Rails應用更容易閱讀。內(nèi)建的測試框架還簡化了單元、功能和集成測試。Ruby的動態(tài)特性又使得Rails應用更易于擴展。這一切加起來，無一不使得長期維護和擴展變得更加容易。
真正的阻力
一般的管理人員會把新技術(shù)視為巨大的霓虹燈一樣的風險標志，理由也很充分。新技術(shù)生來就帶有風險，而新的編程語言則把風險帶到一個全新的高度，因為使用新語言的決策會持續(xù)影響到你應用程序的整個生命周期。以下令人煩心的風險是很有說服性的：
你可能會選擇一個錯誤的問題。
這門語言可能會變得沒有活力，從而限制了今后的支持和增強。
從技術(shù)上說，這門語言可能導致無法交付。
這門語言可能會引起長期性問題，而這些問題目前還尚未明了。
你可能無法理解這門新技術(shù)。
當這一切和從Java遷移到Ruby上有關(guān)的時候，你就得站在超出技術(shù)爭論的層面上，說服技術(shù)決策人，告訴他Ruby所能提供的商業(yè)價值完全可以克服采用一門新語言所能帶來的風險。你的潛在收益會令風險顯得如同九牛一毛，而你的領路人必須能毫無疑問地證明出你能獲得的收益。
你的試點策略
為了寫《FromJavatoRuby》一書，我采訪了不少開發(fā)人員，他們已經(jīng)或者正在使用Ruby構(gòu)建產(chǎn)品級應用。我探索了讓Ruby成功在各種不同公司樹立威信的試點策略。領路人的目的通常有兩個方面：
技術(shù)風險軸線。高技術(shù)風險索帶來的問題能幫助人們更多地了解手中研究的技術(shù)。
政策風險軸線。你需要懷疑精神，來見證一項技術(shù)的成功，這樣你才能使用它。
通常，這兩個目標常常能引起爭論。要把觀點兜售出去，一般來說技術(shù)風險較小，因為你不可能用失敗的案例來作為賣點；不過需要的政策方面的風險就高得多了，原因是可見性。學習需要稍微多一些的技術(shù)風險，因為僅僅多搞出一個To-do列表或者Blog并不能使你學會某樣東西。而更高的技術(shù)風險常常會發(fā)生在較低的政策風險的背景下。
做任何成功的試行計劃的第一步，就是做出一個有效的計劃，用于平衡這兩個目標，并且要充分利用手中的資源。這些策略直接來自于這本書。我從應用這門技術(shù)成功交付可工作的產(chǎn)品級應用的Ruby開發(fā)人員學到了里面的每一點。
木馬計（TrojanHorse）
許多技術(shù)人員想方設法嘗試使用Ruby來吸引眼球，卻因為公司的政策原因和拒絕風險的理念而草草收場。幾經(jīng)挫折之后，他們就偃旗息鼓了。而木馬計（TrojanHorse）在那些對新技術(shù)引入緩慢的公司中往往行之有效。你可以使用這個策略來暗度陳倉，在眼皮底下把Ruby整合進系統(tǒng)。通常的辦法就像這樣：
先找到一個不那么令人興奮的技術(shù)問題。
私底下使用Ruby解決此問題，盡可能在管理層發(fā)現(xiàn)不了的情況下工作。
創(chuàng)建一個草根階級聯(lián)盟，通過培養(yǎng)文化的方式培養(yǎng)Ruby布道者。
木馬戰(zhàn)術(shù)的技術(shù)風險不高，而且政策風險也很低。你的目標就是利用簡單的問題建立早期戰(zhàn)功，通過內(nèi)部技術(shù)營銷來建立起擁護者陣營，在你建立起更多影響之后，你就可以拓展你的技術(shù)和政策活動范圍了。
Amazon.com就是一個通過木馬計在早期建立群眾基礎的公司的成功范例。曾在Amazon.com供職、目前在Google的SteveYegge，是一個編程語言狂熱愛好者，他在許多年前就開始使用Ruby。他和其他幾個人一起，讓開發(fā)人員相信Ruby對于他們是可用的。一些Ruby遠見卓識者，包括DaveThomas（最熱銷的Ruby書的作者和出版者）和DavidHeinemeierHannson（Rails的作者），都一一在Amazon.com做過講演，只不過Ruby在那兒僅被用作腳本語言。但是，Ruby的社區(qū)在成長，而它的應用也越變越廣泛了。
我也給另外一家公司服務過，這家公司就擁有一次絕佳的機會來演繹木馬計。有一家歐洲咨詢公司曾從事一個Java項目的開發(fā)，還沒來得及構(gòu)建管理控制臺就已經(jīng)資金短缺了。他們沒能開發(fā)出一套控制臺，結(jié)果客戶只能直接使用SQL來管理數(shù)據(jù)庫，這樣使得他們不得不在數(shù)據(jù)完整性問題上面臨相當大的風險。我們認定，使用RubyonRails來構(gòu)建這樣的控制臺根本就是小菜一碟，但用Java卻是費時費力。不過后來這個客戶是否使用Rails取得進展，后來我就不得而知了。
反對意見
使用木馬計的策略，你的目標就是通過暗度陳倉來消除反對意見。如果你著實面臨反對聲音，你應當將Ruby定位成和Perl、HTML、SQL或者XML一樣的工具型腳本語言。
在這一切都已經(jīng)說到并且做到之后，木馬計無非就是一次純粹的草根顛覆運動。有耐心地培育肥沃的土壤，這樣你種下的草種才能長成茂密的草原。通過小的積累來建立起成功的大廈，你就可以投下賭注，相信自己可以使Ruby項目得以成長，或者在企業(yè)中擴大Ruby的地位。這時候你常常不會選擇走正式的官方批示路線，或者你會選擇基于你解決的問題中不那么重要的部分來繞行。
項目競賽（TheRace）
到目前位置我碰到的最有意思的情況就是項目競賽了。前提如下：
你拿到一個費時費力的問題，這個問題已經(jīng)在使用Java解決了。
你花費自己的應急預算，開始同步構(gòu)建一個Ruby項目。
你組建一支大約只有Java項目團隊的20%到33%開發(fā)人員數(shù)量的Ruby團隊。
經(jīng)過一段時間以后，選擇進度完成得最多的一個項目。
在這個情況下，Ruby項目的技術(shù)風險是很高的，不過你希望同時進行一個Java項目來抵消這樣的風險。項目競賽會是Ruby生產(chǎn)力的一個很有力的例證。不利方面則是失敗的代價。如果你失敗了，你會以給兩個開發(fā)項目注資的結(jié)果而告終。但是，如果你成功了，從長期角度看，你將花費較少的成本。從實際角度考慮，Ruby項目變成了高風險的焦點，隨之而來的是非常高的潛在回報，而并行的Java項目則變成一個昂貴的保險。下面是我所聽到的：
有一家咨詢公司在構(gòu)建一個Java項目的同時，以Ruby開發(fā)了同樣的項目，并且自己掏錢為這部分開發(fā)工作買了單。他們將Ruby擺到了戰(zhàn)略性的高度，并且希望使用項目競賽的方法來使客戶相信RubyonRails是一個切實可行的可選方案。
有一名開發(fā)人員提議每周花一天時間使用Ruby開發(fā)，剩下的四天使用Java。他的管理人員可以在一個月左右之后選擇最佳的解決方案。
還有一家咨詢公司使用Java和Ruby創(chuàng)建原型，從而展示Ruby解決方案的高效。
這個策略本身是不太和諧的，不過對于說服那些有好奇心但不希望拍板的管理者來說是非常有用的。項目競賽方案對Ruby爆炸性生產(chǎn)力的展示能力是其它方法所不能匹敵的。在我碰到的四個項目競賽方案中，有兩個成功了，第三個還沒有完成，而第四個則控制在預算之內(nèi)，并且領先于進度，但是失去了資金援助。
實際上，項目競賽方案并不比你想象的激進，在管理層認為Ruby也許可以帶來成倍生產(chǎn)力的情況下尤其如此。盡管這樣做的代價很高，但是這種方案是風險最低的幾種Ruby方案之一。不過，還是要小心。不利因素之一就是，即便你的試行項目已經(jīng)開始進行，Java仍會作為一種備選方案，甚至在你成功的時候都是如此。你可以在技術(shù)上取得成功，但是在行政上仍然無法讓你的例子說明問題。我采訪的客戶之一成功地完成了一個Ruby的試行項目，在投入上卻只有Java項目的1/4。這個客戶非常喜歡這個“原型”，并且要求用Java來完成它。
反對意見
對于項目競賽的方案，最大的反對意見就是項目的開支。對于這樣的反對意見，你的回應應當不帶感情因素，并且理由也要非常充分。如果成功的話，你的總體開支將比一個完整Java項目要少很多。不信就想想，在同樣一個項目中Ruby的生產(chǎn)力能達到四倍之強，例如經(jīng)典的Rails應用就是如此。如果管理層決定開上“鐵道”，并在一半的時候終止項目的Java部分，那么你的總體開支就僅需從頭開發(fā)Java項目開支的75%。如果你在項目25%的時候就用Ruby開工，那么根據(jù)使用一項更具生產(chǎn)力的技術(shù)完成項目的結(jié)果，項目的整體開支僅需全用Java方案的25%。令人驚奇的是，你獲取收支平衡的點可以是項目進度的75%。
我在這里展示的兩個試點項目僅僅只是我看見的兩種不同的方式。這里還有更多其它方式你可以來借鑒：
實現(xiàn)一個傳統(tǒng)的試點項目，強調(diào)學習而不是兜售好處。
通過小團隊使用Ruby的方式挽救一個行將失敗的Java項目。
在Java項目的競標上降低成本，并且相信你可以使用更少的總體成本來制勝。比如說，我就曾經(jīng)成功地以低30%的固定競標價格勝過最有優(yōu)勢的Java固定競標價格。
展示諸如領域特定語言或者Ajax集成等旗艦級框架能力。
當然，其它高效的技術(shù)也還是存在的。在一些公司里，比如在那些擁有Ruby強有力支持者的公司中，Ruby相對來說會比較容易兜售出去的。在這些例子里，領路人的職責發(fā)生了變化。你得強調(diào)學習，而不是兜售好處。在所有的例子里，你都必須不斷保持工作狀態(tài)才能使球向前滾。
將成功轉(zhuǎn)化為資本
利用一個成功的試點來使你領先于進度表的絕對關(guān)鍵就是數(shù)據(jù)。你將需要收集真實而準確的度量來描述你的成功。盡管你常常會去強調(diào)生產(chǎn)力，但對于以下經(jīng)常存在主要反對意見的領域，你也得拿出實際數(shù)據(jù)出來：
性能數(shù)據(jù)——對Ruby的常見反對理由之一，就是缺乏伸縮性。一般來說這個反對意見是沒有事實依據(jù)的。
上手速度（Rampup）——由于目前可用的人才儲備，大多數(shù)會期望Java開發(fā)人員上手速度比Ruby開發(fā)人員的快。實際上，Rails項目上手是非?？斓摹?/p>
團隊規(guī)?！@個論據(jù)常常非常有說服力。開發(fā)人員數(shù)量少，實際上卻能做更多的事情。
代碼行數(shù)——統(tǒng)計代碼的總行數(shù)，但不要忘記算上配置的行數(shù)。
這個額外的努力并不會浪費你很多時間，但會讓把成功轉(zhuǎn)化為資本的努力變得容易得多。當你在一個Java的環(huán)境中為Ruby樹立威信的時候，請不要忘記，你有一個不應逃避的任務，那就是向眾人展示項目中的顯著改善。成功的關(guān)鍵在于平衡你的技術(shù)目標和政策目標。你必須決定有哪些東西在你的政策環(huán)境中行之有效，以及你的團隊能發(fā)揮的技術(shù)實力如何。如果你想有效說服大家從Java倒戈投向Ruby的陣營，那么請啟動一個Ruby試點項目，在正確的環(huán)境中解決正確的問題。讓Ruby語言用事實說話。
