Relevance 咨询公司的 Stuart Halloway 最近编写了一个关于“Ruby vs. Java 之怪谈”的系列博客文章。这个系列文章的灵感，源自他最近从一个从零起步、没有先前约束的 Ruby 项目转回一个成熟完备的 Java 项目后的心得体会。在这个历时多日的项目过程中，Halloway 对以下几个“误区”进行了探索：
误区之一：Ruby 适合小型项目，而 Java 更适用于大型的、复杂的项目。
概括起来， Halloway 主张，对于小型项目来说，诸如未知因素一类的问题可能会使进度表大幅度改动，而如果找到一个成熟完善的代码库则可以使得开发人员几乎不用编写多少代码。在 Java 方面，这些因素是很大的一个优势，因为它背后有一个成熟强大的社区和一群非常有经验的开发人员所支持。对于大型项目，Halloway 则称，诸如语言的生产效率之类的因素会比代码库更为紧要，这也把天平上优势的砝码放在了 Ruby 一端。他指出，目前事实已经发生逆转，并解释说：
当前 Ruby 异常适合的一种小型项目是：由数据库所支撑的 Web 应用，因为 Ruby on Rails 抵消掉了所有 Ruby 在小型项目方面的不利因素。
误区之二：Ruby 的某某特性使得代码难以维护
针对这个认识误区，Halloway 的结论是：如果使用得当，Ruby 的语言特性会使用其编写的代码更加易于维护。对于“易于维护的代码”的概念，他给出以下定义：
- 理解应用程序或者模块的总体设计思路
- 找到你所需要的代码
- 阅读代码
- 对代码进行变更
- 检查变更是否正常运行
下面是两种语言的优势对比：
理解应用程序或者模块的总体设计思路：无一胜出
[…] 我的经验表明，在这个方面没有哪个语言能帮上很多忙，但良好的抽象概念会有所帮助。Java 和 Ruby 包含很多相同的抽象概念：实现继承、类、多态和封装等等。
查看你所需要的代码：Java 胜出
由于 IDE 的有效支持，Java 在这个方面胜出。
阅读代码：Ruby 胜出
结论：Ruby 代码更容易保持 DRY 原则，因此更容易阅读。
对代码进行变更：Ruby 胜出
结论：在动态语言中进行代码变更更为容易。
检查变更是否正常运行：不相伯仲
Ruby 和 Java 都提供了对单元测试、验收测试和持续集成等方面的良好支持。
误区之三：Ruby 太难了
有些人，比如 Cedric Beust 主张说，对于普通开发人员 Ruby 的难度太大。Halloway反驳到，总的来说，编程就不是一件容易的事情。尽管有些丛书以“21 天学会编程”的旗号为噱头，但这是不可能的。因此，使用 Java 和 Ruby 编程都不是一件容易的事情。他主张说：
[…] 你不能通过限制语言的特性这种方式来降低难度 […]
误区之四：要抄袭 Rails 的创意很容易
Halloway 提出，这个误区需要慎重看待，因为它说的确实有一部分是真的。Rails 的许多创意是可以被抄袭到其它任何语言上去的。但是，对于这个观点的反驳也存在：
[…] 另外一些创意则取决于特定的 Ruby 语言特性。Rails 使用了 open class，使得我们可以写出更好的、可读性更强的对象模型。举例而言，你可以写出
x.blank?这样的代码，而不是这样：StringUtilities.isBlank(x)。单独来说，这样的区别并不会产生很大的意义，但是随着它们积少成多了以后，代码的可读性就会得到显著的提升。[…]
误区之五：这是一场没有赢家的游戏
最后是系列文章的总结陈词：作为一门语言，Ruby 胜出；但作为一个平台，Java 胜出——
那么，我们所有人难道不能和睦相处么？我多希望在我所生活的世界中，对语言的偏好并不会给一名程序员贴上什么标签。我们可以用 Ruby、Scheme、Scala 或者 Erlang 来编写代码，而且任何地方的 JVM 都是我们所可以生存的和谐社会。
为了让这样的和谐氛围得以延续，Halloway 对应当采取的行动给出了以下建议：为 JRuby 项目贡献代码，并在今后的 Java 应用中使用 Rake 而不是 Ant 来管理。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论