java ruby_从Java到Ruby：试点策略

java ruby

现在，许多开发人员都知道Ruby on Rails是当今最重要的开源项目之一。 增长背后的引擎-高生产力-在具有相似市场份额的框架中是无与伦比的。 虽然其他框架的生产力令人印象深刻，但是没有其他框架能够将技术创新和市场份额相结合。 现在，Rails社区贡献了大量的插件（称为Gems），书籍（今年有10本书），培训，大型会议和令人印象深刻的在线资源库。 随着Rails的轰动，即使是最保守的公司也将开始考虑Ruby。

但是到目前为止，这是开发人员领导的一场革命。 有说服力的管理需要另一种说服力。 经理需要了解采用Ruby的风险，不喜欢Java等主流语言（甚至对于一个项目）的风险以及Ruby功能的整体技术前景。 坦率地说，在这方面目前的文献不足。 本系列文章基于从Java到Ruby ，将探讨保守领域中Ruby的三个方面的应用：试点项目，理解风险以及Java / Ruby集成策略。

试点方法

Ruby是一种出色的语言。 如果要在一家保守的公司中建立它，请使用该语言实施试点项目，以在适当的情况下解决适当的问题。 让Ruby做其余的事情。 但是，为了建立您的试验项目，您需要首先构建一个使Ruby足够吸引风险的案例。 然后，您需要为试点策略添加一些结构。 面对采用新语言所固有的阻力，您希望选择一种毫无疑问的方法。 最后，您将要奠定成功的政治基础。

因此，您的第一步应该是建立奖励，并且要有足够的吸引力来克服采用新语言的风险。 使用Ruby，构建案例比您想象的要容易。

寻找引人注目的奖励

一切都说完了，您的核心优势可能会围绕短期和长期生产力。 短期生产力可处理您的应用程序的即时开发。 长期生产率包括应用程序的整体维护和简化。 像大多数脚本语言一样，Ruby在短期生产力方面也很出色。 与典型的脚本语言不同，早期迹象表明，Ruby在长期问题（例如易于维护，简单和可扩展）上也应表现出色。

Ruby和旗舰Rails框架带来了显着的生产率提高，对于某些应用程序通常接近三到五分之一。 提高生产率时，可以缩小团队规模，降低通信成本并消除开销。 较小的团队也可以提高敏捷开发流程的效率。 这些改进的乘数效应通常被低估了。

开发人员了解动态类型，元编程，领域特定语言以及更丰富的抽象（如闭包和延续）的影响。 Ruby on Rails框架还有更多革命性的功能，而Java框架中尚未重复这些功能。 快速的反馈周期，预测试，配置约定和革命性的持久性框架都对Java开发人员具有吸引力。 但是，您无法摆脱功能集，不能期望与中层管理人员交谈时争论的影响会持续下去。 您需要根据生产率来表达这些功能。

也存在长期利益。 减少的配置，惊人的简单性，更少的代码行以及特定于域的语言通常使Rails应用程序更易于阅读。 内置测试框架简化了单元，功能和集成测试。 Ruby的动态特性使Rails应用程序更易于扩展。 这些属性合在一起，可以更轻松地进行长期维护和扩展。

真正的抵抗

典型的经理将新技术视为巨大的霓虹灯风险标志，这是有充分理由的。 新技术具有内在的风险，新的编程语言将风险带到了一个全新的高度，因为这种决定将持续到您应用程序的整个生命周期。 这些令人担忧的风险具有说服力：

• 您可能会选择错误的问题。
• 该语言可能会停滞不前，从而限制将来的支持和增强。
• 该语言可能无法在技术上提供。
• 该语言可能会导致尚不清楚的长期问题。
• 您可能不了解新技术。

当一切都归结为从Java到Ruby的转变时，您需要超越技术论点，使技术决策者相信Ruby可以提供足够的业务价值，以克服采用新语言的固有风险。 您的潜在报酬必须掩盖风险，您的飞行员必须毫无疑问地证明您的利益。

您的试点策略

在《 从Java到Ruby》中 ，我采访了数十位已在Ruby中构建或正在构建生产应用程序的开发人员。 我探索了在各种公司中建立Ruby的试验策略。 飞行员的目标通常有两个：

• 技术风险轴。 技术风险高的问题可帮助您了解有关正在探索的技术的更多信息。
• 政治风险轴。 您希望怀疑论者看到该技术成功，以便可以使用它。

通常，这些目标是矛盾的。 销售通常要求较少的技术风险，因为您不能出售失败，但提高可见度的政治风险。 学习需要更多的技术风险，因为您不会通过建立另一个待办事项列表或博客来学习任何东西。 通常，较高的技术风险是在较低的政治风险的背景下进行的。

规划任何成功的飞行员的第一步是规划一个有效的策略，以平衡这些目标并利用您的手头资源。 这些策略直接来自本书。 我从Ruby开发人员那里学到了每一个应用该技术来交付有效的生产应用程序的方法。

特洛伊木马

许多技术专家试图对Ruby进行大刀阔斧的宣传，结果却对政治和规避风险的哲学感到沮丧。 几番挫折后，他们退出了。 特洛伊木马程序通常在那些非常缓慢地采用新技术的公司中表现良好。 通过这种策略，您可以将Ruby移入雷达下的系统。 这是一般的想法：

• 您会发现一个令人兴奋的技术问题。
• 您可以使用Ruby安静地解决问题，并尽可能减少管理可见性。
• 您建立了一个基层运动，通过培养文化来培养Ruby传福音者。

特洛伊木马的技术风险较低，政治风险也较低。 您的目标是建立一些具有简单问题的早期成功，通过内部传播建立技术拥护者，并随着积累的影响力扩大技术和政治范围。

Amazon.com是公司通过特洛伊木马技术建立Ruby的早期阶段的一个很好的例子。 史蒂夫·耶格（Steve Yegge）是一名编程语言爱好者，曾在Amazon.com工作，但现在在Google工作，他几年前开始使用Ruby。 与其他许多人一样，他确保Ruby对开发人员可用。 一些Ruby远见者，包括Dave Thomas（最受欢迎的Ruby书籍的作者和出版商）和David Heinemeier Hannson（Rails的创建者），都在Amazon.com上发言，尽管Ruby仅在此处用作脚本语言。 但是社区在增长，用途也在扩大。

我在另一家公司，该公司有很好的机会实施特洛伊木马程序。 一家欧洲咨询公司从事Java项目，在他们无法建立管理控制台之前就用光了资金。 客户无需构建控制台，而是使用直接SQL管理数据库，并且面临数据完整性问题的巨大风险。 我们认为控制台在Ruby on Rails中构建很简单，但对Java的要求很高。 我从未发现这个客户是否会继续使用Rails。

异议

在特洛伊木马方案中，您的目标是通过不引起注意消除异议。 如果确实遇到异议，则将尝试以与Perl，HTML，SQL或XML相同的精神将Ruby定位为实用程序脚本语言。

总而言之，特洛伊木马纯粹是草根游戏。 您寻求耐心地为草生长肥沃的土壤。 通过逐步取得成功，您打赌您将能够发展Ruby项目或Ruby在企业中的角色。 您通常会选择不进行正式的批准流程，或者根据要解决的问题的重要性不高来解决该流程。

种族

到目前为止，我遇到的最有趣的场景是Race场景。 前提是：

• 您会遇到一个用Java已经解决的苛刻问题。
• 您将应急预算用于并行构建Ruby项目。
• 您建立的团队的Java项目开发人员人数大约为20％到33％。
• 一段时间后，选择最远的项目。

在这种情况下，Ruby项目的技术风险很高，但是您希望通过并行执行Java项目来弥补这种风险。 Race场景很好地证明了Ruby的生产力。 缺点是失败的代价。 如果失败，您将在一段时间内为两项开发工作投入资金。 但是，如果您成功了，从长远来看，您的支出会减少很多。 实际上，Ruby项目成为具有很高潜在收益的高风险焦点，而并行Java项目则成为昂贵的保险。 如果以下是我听说过的比赛场景的一些信息：

• 一家咨询公司与Java项目同时构建了一个Ruby项目，并自行资助了开发工作。 他们认为Ruby具有战略意义，并希望使用Race场景使客户相信Ruby on Rails是可行的选择。
• 一位开发人员提议花一天的时间在Ruby中进行开发，花四天时间在Java中进行开发。 经理可以在一个月左右后选择最佳解决方案。
• 一家咨询公司在Java和Ruby中构建了原型，以证明Ruby解决方案的有效性。

这种策略有点刺耳，但对于说服感兴趣但不愿动手的管理者来说很有用。 Race场景展示了Ruby前所未有的爆炸式生产力。 在我遇到的四个比赛场景中，有两个成功了，第三个尚未完成，第四个项目在预算之内且提前完成，但资金损失。

Race场景实际上并不像您预期​​的那样激进，特别是如果管理团队认为Ruby的生产力可能要高出许多倍。 尽管费用很高，但是这种情况是风险最低的Ruby情况之一。 不过要小心。 缺点之一是即使您进行了试验，即使您成功了，Java仍然是一种选择。 您可以在技术上取得成功，但仍无法在政治上提出您的要求。 我采访过的一位客户成功完成了Ruby试点，费用仅为Java预测成本的1/4。 客户喜欢“原型”，并要求用Java完成它。

异议

对于“竞赛”场景，最大的反对是成本。 您对这个异议的回应应该没有感情色彩，而且要有充分的理由。 如果你成功了，你的总成本很可能低于完成的Java项目。 考虑一个项目，其中Ruby的生产率是传统的Rails应用程序的四倍。 如果管理层决定骑Rails并在项目进行到一半时报废Java方面，那么总成本将仅是从头开始构建Java项目成本的75％。 如果您在整个项目中25％的时间都在Ruby上使用触发器，那么基于以更高生产率的技术完成该项目，整个项目将仅花费Java总工作量的50％。 令人惊讶的是，您的收支平衡点是整个项目过程的75％！

我在这里展示的两个试点项目只是我所看到的两种方法。 您可以采用许多其他方法：

• 实施经典试点，强调学习胜过销售。
• 通过与Ruby一起使用小型团队来拯救失败的Java项目。
• 为Java项目出价低，押注您可以用更少的精力就能成功。 例如，我已经成功提交了固定出价项目，该项目的价格比最佳固定Java出价低30％。
• 展示旗舰框架功能，例如特定领域的语言或Ajax集成。

当然，还存在其他有效的技术。 在某些公司中，例如那些拥有强大Ruby倡导者的公司，Ruby将是相对容易出售的。 在这些情况下，飞行员的角色会发生变化。 您将要强调学习而不是销售。 在每种情况下，您都需要继续努力以保持球不断滚动。

利用成功

利用成功的飞行员来推进议程的绝对关键是数据。 您将需要收集描述您的成功的诚实，准确的指标。 通常，您将要强调生产力，但同时也要在可能存在重大异议的领域中显示实用数据：

• 性能数据。 Ruby常见的反对意见是缺乏可伸缩性。 这种反对通常不是现实存在的。
• 斜坡上升。 根据可用的人才库，大多数管理人员都希望比Ruby同行更快地增加Java开发人员。 Rails的上升实际上非常快。
• 团队规模。 这种说法通常很引人注目。 您可以事半功倍。
• 代码行。 计算总行数，但不要忽略配置行。

这项额外的工作不需要花费很多时间，但是可以更轻松地利用成功。 当您在Java环境中建立Ruby时，请记住，您将不得不展示出惊人的改进。 关键是要平衡您的技术和政治目标。 您需要确定在您的政治环境中什么可行，以及您的团队可以提供多少技术能力。 如果您想有效地针对Java出售Ruby，请使用Ruby试点在正确的环境中解决正确的问题。 让语言为自己说话。

翻译自: https://www.infoq.com/articles/From-Java-to-Ruby--Strategies/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

java ruby