【IT168 技术新闻】现在，有许多开发人员知道Ruby on Rails是目前最为重要的开源项目之一。卓著的生产力——这个成长背后的动力，是其它与其市场份额相近的框架所不能匹敌的。尽管其它的框架也同样在鼓吹自己拥有如何非凡的生产力，但它们当中却没有哪个能配得上拥有技术创新和市场占有率的创新组合这一称号。如今，Rails社区贡献出了广泛的插件（称为Gems）、书籍（光2006年就有10本关于Rails的书籍问世）、培训、一个主要会议，以及一个令人称道的在线资源库。随着Rails风头正劲，甚至连最保守的公司都开始考虑采用Ruby。

不过，到目前为止这还只是一场开发者领导的革命，要说服管理层则要令费一番口舌了。管理人员必须了解采用Ruby带来的风险，让主流语言（如Java）坐冷板凳所带来的风险——哪怕仅对一个项目，还有Ruby语言能力的技术全貌。坦白说，目前这方面的文字很少。以《From Java to Ruby》一书为基础，这个系列的文章将在下面三个方面探索如何在保守的公司采用Ruby：试点项目（Pilot Projects），了解风险，以及Java与Ruby的整合策略。

引路人之道

Ruby是一门优秀的语言。倘若你想在一家保守的公司里为它树立威望，那么请在正确的环境下使用它实现一个试点项目来解决正确的问题。剩下的工作让Ruby完成就可以了。不过，为了建立你的试点项目，你首先需要创建一个案例，让Ruby看起来足够吸引眼球，从而让大家甘心冒这个风险。接着，你得在你的试点策略里面添筋加骨。鉴于人们对采用一门新语言与生俱来的抵抗力，你要选择一个不给疑虑留任何余地的方法。最终，你得愿意为成功建立制度根基。

因此，你的第一步就应当是树立回报的价值，一个具备足够说服力的效益，来克服采用新语言带来的风险。有了Ruby，构建你的案例要比你想象的容易得多。

找到一项有说服力的回报

在所有东西都说到而且做到了之后，你的核心优势就会在短期和长期的生产力上不断表现喷涌而出。短期生产力即你可以迅速地构建出一个应用。就像大部分的脚本语言一样，Ruby在短期生产力上表现不凡。但是常见的脚本语言不同的是，早期的迹象表明，在较长期的问题上，例如易维护性，简单性，扩展性等方面，Ruby同样会表现得卓尔不群。

Ruby，还有它的旗舰级Rails框架，能带来引人注目的生产力提升，对于某些应用程序来说常常能接近三到五倍。当你把生产力提高了之后，你就可以缩小团队的规模、削减沟通的开销，并消除额外的浪费了。同时，小型的开发团队还可以提升敏捷开发过程的效率。这些改善所带来的成倍影响常常没有被人充分说明展现出来。

开发人员们对动态类型（Dynamic Typing）、元编程（Metaprogramming）、领域特定语言（Domain Specific Languages），以及更丰富的抽象特性，如闭包（Closures）和Continuations等，所能带来影响的了解是颇为深刻的。Ruby on Rails框架也还有一些革命性的特性还没有在Java框架中被重现出来。对于Java开发人员来说，快速的反馈周期、内建的测试功能、约定优于配置（Convertion over Configuration）和革命性的持久层框架都足以令人眼睛放光。然而，当你在和你的中层管理人员交谈的时候，你不可能跟他们滔滔不绝地背诵完这些特性列表，然后开始期待你的论据就是一针见血的。你必须从生产力的角度来表述这些特性。

更长期的优势也是存在的。削减的配置、惊人的简易程度、更少的代码行数，还有领域特定语言，这一切都使得Rails应用更容易阅读。内建的测试框架还简化了单元、功能和集成测试。Ruby的动态特性又使得Rails应用更易于扩展。这一切加起来，无一不使得长期维护和扩展变得更加容易。

真正的阻力

一般的管理人员会把新技术视为巨大的霓虹灯一样的风险标志，理由也很充分。新技术生来就带有风险，而新的编程语言则把风险带到一个全新的高度，因为使用新语言的决策会持续影响到你应用程序的整个生命周期。以下令人烦心的风险是很有说服性的：

你可能会选择一个错误的问题。
这门语言可能会变得没有活力，从而限制了今后的支持和增强。
从技术上说，这门语言可能导致无法交付。
这门语言可能会引起长期性问题，而这些问题目前还尚未明了。
你可能无法理解这门新技术。
当这一切和从Java迁移到Ruby上有关的时候，你就得站在超出技术争论的层面上，说服技术决策人，告诉他Ruby所能提供的商业价值完全可以克服采用一门新语言所能带来的风险。你的潜在收益会令风险显得如同九牛一毛，而你的领路人必须能毫无疑问地证明出你能获得的收益。

你的试点策略

为了写《From Java to Ruby》一书，我采访了不少开发人员，他们已经或者正在使用Ruby构建产品级应用。我探索了让Ruby成功在各种不同公司树立威信的试点策略。领路人的目的通常有两个方面：

技术风险轴线。高技术风险索带来的问题能帮助人们更多地了解手中研究的技术。
政策风险轴线。你需要怀疑精神，来见证一项技术的成功，这样你才能使用它。
通常，这两个目标常常能引起争论。要把观点兜售出去，一般来说技术风险较小，因为你不可能用失败的案例来作为卖点；不过需要的政策方面的风险就高得多了，原因是可见性。学习需要稍微多一些的技术风险，因为仅仅多搞出一个To-do列表或者Blog并不能使你学会某样东西。而更高的技术风险常常会发生在较低的政策风险的背景下。

做任何成功的试行计划的第一步，就是做出一个有效的计划，用于平衡这两个目标，并且要充分利用手中的资源。这些策略直接来自于这本书。我从应用这门技术成功交付可工作的产品级应用的Ruby开发人员学到了里面的每一点。

木马计（Trojan Horse）

许多技术人员想方设法尝试使用Ruby来吸引眼球，却因为公司的政策原因和拒绝风险的理念而草草收场。几经挫折之后，他们就偃旗息鼓了。而木马计（Trojan Horse）在那些对新技术引入缓慢的公司中往往行之有效。你可以使用这个策略来暗度陈仓，在眼皮底下把Ruby整合进系统。通常的办法就像这样：

先找到一个不那么令人兴奋的技术问题。
私底下使用Ruby解决此问题，尽可能在管理层发现不了的情况下工作。
创建一个草根阶级联盟，通过培养文化的方式培养Ruby布道者。
木马战术的技术风险不高，而且政策风险也很低。你的目标就是利用简单的问题建立早期战功，通过内部技术营销来建立起拥护者阵营，在你建立起更多影响之后，你就可以拓展你的技术和政策活动范围了。

Amazon.com就是一个通过木马计在早期建立群众基础的公司的成功范例。曾在Amazon.com供职、目前在Google的Steve Yegge，是一个编程语言狂热爱好者，他在许多年前就开始使用Ruby。他和其他几个人一起，让开发人员相信Ruby对于他们是可用的。一些Ruby远见卓识者，包括Dave Thomas（最热销的Ruby书的作者和出版者）和David Heinemeier Hannson（Rails的作者），都一一在Amazon.com做过讲演，只不过Ruby在那儿仅被用作脚本语言。但是，Ruby的社区在成长，而它的应用也越变越广泛了。

我也给另外一家公司服务过，这家公司就拥有一次较好的机会来演绎木马计。有一家欧洲咨询公司曾从事一个Java项目的开发，还没来得及构建管理控制台就已经资金短缺了。他们没能开发出一套控制台，结果客户只能直接使用SQL来管理数据库，这样使得他们不得不在数据完整性问题上面临相当大的风险。我们认定，使用Ruby on Rails来构建这样的控制台根本就是小菜一碟，但用Java却是费时费力。不过后来这个客户是否使用Rails取得进展，后来我就不得而知了。

反对意见

使用木马计的策略，你的目标就是通过暗度陈仓来消除反对意见。如果你着实面临反对声音，你应当将Ruby定位成和Perl、HTML、SQL或者XML一样的工具型脚本语言。

在这一切都已经说到并且做到之后，木马计无非就是一次纯粹的草根颠覆运动。有耐心地培育肥沃的土壤，这样你种下的草种才能长成茂密的草原。通过小的积累来建立起成功的大厦，你就可以投下赌注，相信自己可以使Ruby项目得以成长，或者在企业中扩大Ruby的地位。这时候你常常不会选择走正式的官方批示路线，或者你会选择基于你解决的问题中不那么重要的部分来绕行。

项目竞赛（The Race）

到目前位置我碰到的最有意思的情况就是项目竞赛了。前提如下：

你拿到一个费时费力的问题，这个问题已经在使用Java解决了。
你花费自己的应急预算，开始同步构建一个Ruby项目。
你组建一支大约只有Java项目团队的20%到33%开发人员数量的Ruby团队。
经过一段时间以后，选择进度完成得最多的一个项目。
在这个情况下，Ruby项目的技术风险是很高的，不过你希望同时进行一个Java项目来抵消这样的风险。项目竞赛会是Ruby生产力的一个很有力的例证。不利方面则是失败的代价。如果你失败了，你会以给两个开发项目注资的结果而告终。但是，如果你成功了，从长期角度看，你将花费较少的成本。从实际角度考虑，Ruby项目变成了高风险的焦点，随之而来的是非常高的潜在回报，而并行的Java项目则变成一个昂贵的保险。下面是我所听到的：

有一家咨询公司在构建一个Java项目的同时，以Ruby开发了同样的项目，并且自己掏钱为这部分开发工作买了单。他们将Ruby摆到了战略性的高度，并且希望使用项目竞赛的方法来使客户相信Ruby on Rails是一个切实可行的可选方案。
有一名开发人员提议每周花一天时间使用Ruby开发，剩下的四天使用Java。他的管理人员可以在一个月左右之后选择非常好的的解决方案。

还有一家咨询公司使用Java和Ruby创建原型，从而展示Ruby解决方案的高效。
这个策略本身是不太和谐的，不过对于说服那些有好奇心但不希望拍板的管理者来说是非常有用的。项目竞赛方案对Ruby爆炸性生产力的展示能力是其它方法所不能匹敌的。在我碰到的四个项目竞赛方案中，有两个成功了，第三个还没有完成，而第四个则控制在预算之内，并且领先于进度，但是失去了资金援助。

实际上，项目竞赛方案并不比你想象的激进，在管理层认为Ruby也许可以带来成倍生产力的情况下尤其如此。尽管这样做的代价很高，但是这种方案是风险最低的几种Ruby方案之一。不过，还是要小心。不利因素之一就是，即便你的试行项目已经开始进行，Java仍会作为一种备选方案，甚至在你成功的时候都是如此。你可以在技术上取得成功，但是在行政上仍然无法让你的例子说明问题。我采访的客户之一成功地完成了一个Ruby的试行项目，在投入上却只有Java项目的1/4。这个客户非常喜欢这个“原型”，并且要求用Java来完成它。

反对意见

对于项目竞赛的方案，最大的反对意见就是项目的开支。对于这样的反对意见，你的回应应当不带感情因素，并且理由也要非常充分。如果成功的话，你的总体开支将比一个完整Java项目要少很多。不信就想想，在同样一个项目中Ruby的生产力能达到四倍之强，例如经典的Rails应用就是如此。如果管理层决定开上“铁道”，并在一半的时候终止项目的Java部分，那么你的总体开支就仅需从头开发Java项目开支的75%。如果你在项目25%的时候就用Ruby开工，那么根据使用一项更具生产力的技术完成项目的结果，项目的整体开支仅需全用Java方案的25%。令人惊奇的是，你获取收支平衡的点可以是项目进度的75%。

我在这里展示的两个试点项目仅仅只是我看见的两种不同的方式。这里还有更多其它方式你可以来借鉴：

实现一个传统的试点项目，强调学习而不是兜售好处。
通过小团队使用Ruby的方式挽救一个行将失败的Java项目。
在Java项目的竞标上降低成本，并且相信你可以使用更少的总体成本来制胜。比如说，我就曾经成功地以低30%的固定竞标价格胜过最有优势的Java固定竞标价格。
展示诸如领域特定语言或者Ajax集成等旗舰级框架能力。
当然，其它高效的技术也还是存在的。在一些公司里，比如在那些拥有Ruby强有力支持者的公司中，Ruby相对来说会比较容易兜售出去的。在这些例子里，领路人的职责发生了变化。你得强调学习，而不是兜售好处。在所有的例子里，你都必须不断保持工作状态才能使球向前滚。

将成功转化为资本

利用一个成功的试点来使你领先于进度表的绝对关键就是数据。你将需要收集真实而准确的度量来描述你的成功。尽管你常常会去强调生产力，但对于以下经常存在主要反对意见的领域，你也得拿出实际数据出来：

性能数据——对Ruby的常见反对理由之一，就是缺乏伸缩性。一般来说这个反对意见是没有事实依据的。
上手速度（Ramp up）——由于目前可用的人才储备，大多数会期望Java开发人员上手速度比Ruby开发人员的快。实际上，Rails项目上手是非常快的。

团队规模——这个论据常常非常有说服力。开发人员数量少，实际上却能做更多的事情。
代码行数——统计代码的总行数，但不要忘记算上配置的行数。
这个额外的努力并不会浪费你很多时间，但会让把成功转化为资本的努力变得容易得多。当你在一个Java的环境中为Ruby树立威信的时候，请不要忘记，你有一个不应逃避的任务，那就是向众人展示项目中的显著改善。成功的关键在于平衡你的技术目标和政策目标。你必须决定有哪些东西在你的政策环境中行之有效，以及你的团队能发挥的技术实力如何。如果你想有效说服大家从Java倒戈投向Ruby的阵营，那么请启动一个Ruby试点项目，在正确的环境中解决正确的问题。让Ruby语言用事实说话。