神话 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 Tatee已经撰写了9本编程方面的书籍，其中包含两本Ruby的书籍以及五本Java相关的书籍。Bruce还是RapidRed公司的创始人，公司专注于包含Ruby和Rails在内的轻量级开发技术，并提供开发、资讯和培训等业务。Bruce是一位世界范围内广受称赞的优秀演说家、程序员、培训师以及技术顾问。