10

ThoughtWorks咨询师讲述Rails之美

作者: wuzhimin 分类:架构实践   阅读:7,913 次 添加评论

文/胡振波


作为一个有着一年多Rails开发经验的开发人员,笔者希望通过这篇文章跟读者交流和探讨一下Rails开发的心得体会,体验一下Rails之美。

Rails开发之美,我总结的有这样几点:简洁、透明、自由、开放、轻灵、丰富和优美。可能你已经感觉到,这些词汇大多展现的是感性的一面。没错,Rails开发的每一天都是那么畅快,畅快背后其实就是这些生动的感触。笔者希望从这些简单的感触出发,结合实际的例子,来展示Rails真实的美。

Rails之美

简洁

可能很多人在推荐别人使用Rails的时候,都会列举一个理由:简洁。的确,简洁是促使很多人开始学习和使用Rails的原因。那到底什么是简洁?简洁可能代表少,简洁可能代表没有重复,简洁当然也代表复杂的对立面。

Rails是基于ruby语言的。动态语言带来的好处之一是代码量的急剧减少。有一个鲜活的例子,有一次跟客户进行pair,把曾经用Java实现的一个900多行的类,缩减到了100行。客户很是惊讶。当然,纯粹量的减少可能并不代表什么,但至少带来了清晰和易读这两个对代码来说非常重要的特性。

因为动态语言的良好支持,Rails框架使重复的配置工作减少到了极致。比如在Java世界的大量OR Mapping配置文件,在Rails里面不再需要。虽然现在Java世界的配置量也在不断地精简,但还是占据了一定的工作量。重复工作的减少,亦即工作效率的提升。

作为WEB开发领域的DSLRails提供的各种机制在各个层面极大地简化了开发的工作量和难度。比如ActionView提供的FormHelper,简化了页面上form的生成;比如ActiveRecord提供的Association,简化了模型之间关联的维护。

举个association的例子,来看一下Rails的简洁之处。下面这两个模型是一对多的关系:一个lightbox有很多images

class Lightbox < ActiveRecord::Base
end

class Image < ActiveRecord::Base
end


要删除一个lightbox,以及它的所有images,需要这样写:

@images = Image.find_by_lightbox_id(@lightbox.id)
@images.each do |image|
image.destroy
end

@lightbox.destroy


接下来,让我们给它们声明正确的关联关系:

class Lightbox < ActiveRecord::Base
has_many :images, :dependent => :destroy
end

class Image < ActiveRecord::Base
belongs_to :lightbox
end


则删除操作就变得简单了,且在语义和逻辑上更加明确和清晰:
@lightbox.destroy


DSL的一个目的是使某个领域的开发变得更加具体、简单和清晰。Rails框架是从一个现实项目中提炼出来的,这同时也证明了一句话:好的框架都不是凭空想象出来的。
Rails还有很多其它方面可以体现它的简单。简单,就是美。

透明

项目开发过程中,让我觉得很痛快的一件事情是:基本上不需要借助任何外部的文档。
因为Rails本身是透明的,这首先是动态语言提供的好处。当需要了解任何一个方法的功能或者实现时,只需要跳到那个方法查看源代码即可。

同时,对大多数方法,Rails都提供了详尽的文档以及具体的示例。

开放的源代码,以及详尽的注释,让开发人员得以在一个透明的环境上进行开发。开发中可以彻底地了解所用工具的习性,这不可谓不是一件痛快的事情。

自由

对一个问题,Rails往往都提供了多种解决方案。我们可以根据问题的场景,自由地选择合适的方案。

比如对于页面中form的生成,我们可以选择使用form_tag方法。但当这个form跟对象关联的时候,更好的选择是使用form_for方法。结合text_fieldhelper方法,使页面上的元素跟对象的属性更加紧密地结合。

下面再举一个association的例子,来看看Rails如何表现自由的精神。声明多对多关系时,一般是这样的:

class Teacher
has_and_belongs_to_many :students
end

class Student
has_and_belongs_to_many :teachers
end


但有时我们需要利用中间表,并让它映射到一个模型。那么,可以这样来声明模型之间多对多的关联:

class Teacher
has_many :relations
has_many :students, :through => :relations
end

class Relation
belongs_to :teacher
belongs_to :student
end

class Student
has_many :relations
has_many :teachers, :through => :relations
end


选择的多样化带来的是自由。但根据需要和场合选择正确的方案,更加重要。

开放

Rails所体现的一点极其重要的精神是:开放。因为Rails从来不限制你去做任何事情。
有个项目是建立在一个遗留数据库上,并且大多数数据库表结构和遗留数据因为有些原因不能更改。但问题是表结构并不满足Rails的约定,下面列举一些问题和解决办法来窥探一下Rails的开放精神所在。

问题1:单数表名

根据Rails的约定,表名都是复数形式的。比如一个User模型,对应的表名是users。而遗留数据库上的表名是单数形式:user

解决方案

environment.rb文件的配置初始化里,关闭默认的复数表名配置:
config.active_record.pluralize_table_names = false


问题2type字段不代表单表继承

根据Rails的约定,type字段是单表继承的保留字段。当从数据库读取数据并实例化成对象时,它会根据type字段的内容来寻找相应的子类型。但这里type字段并不代表单表继承。

解决方案

在模型里面声明另一个字段代表单表继承,比如:
set_inheritance_column :clazz


问题3type字段的值不满足单表继承的约定

又出现另一个问题,type字段用来表示单表继承,但是它的值并不满足单表继承的约定。根据Rails的约定,type的值应该是类名。比如ShoppingCart继承自ImageCollection,那么type的值应该是“ShoppingCart”。但在遗留数据库里,使用的是“shopping_cart”

解决方案

这里涉及到两个问题,一是在存储一个对象时要设置正确的type值,二是实例化成对象时,需要根据type值找到正确的子类型。通过查看源代码,发现计算type值和子类型的分别是ActiveRecord上的sti_namecomputer_type方法。大家都应该想到了解决方法,就是覆盖这两个方法。对于ShoppingCart类,解决方案可以这样:

def sti_name
super.underscore.upcase
end

def compute_type(type_name)
super(type_name.downcase.camelize)
end


通过上面的例子,我们已经了解了Rails的开放。Rails有很多约定,但不代表强制。而且Rails的开放不仅限于此,比如你可以打开任何一个类,往里面添加方法(当然,这是Ruby给予的权力)。举个例子,比如我们可以通过打开NilClass,来实现Null Object模式(在有些情况下这种做法比较极端):

NilClass.class_eval do
def your_method

end
end


有些语言在天性上对程序员防备多于信任,他们总觉得赋予程序员过多的权力,会容易带来破坏。但其实防止破坏靠的应该是程序员的修炼和自我约束。语言,应该以一种更加开放的态度赋予程序员更多的权利和自由。

轻灵

很多人都觉得Rails是一个庞然大物。但其实Rails并不庞大,DHH在迷思系列里面也解释过。而且,Rails可以轻松剔除任一可选组件。比如要去除ActionControllerbenchmark组件,只要注释掉include ActionController::Benchmarking,并删除相应的文件即可。

在这背后,其实有一个神奇的方法,叫做alias_method_chain。这个方法非常有用,它的设计理念很好地支持了Rails轻灵的特性,因为它让Rails的各个可选组件都只是很轻巧地挂载在上面。继续用Benchmarking这个例子来了解一下它。

Benchmarking的功能是度量action的性能,并把结果输出到日志。这其实是对perform_action方法的增强。从Benchmarking源代码中可以看到如下的代码:
alias_method_chain :perform_action, :benchmark

以及perform_action_with_benchmark方法的实现。

其实,alias_method_chain跟下面的实现是等价的:
alias_method :perform_action_without_benchmark, :perform_action  # 为原来的方法建立别名
alias_method :perform_action, :perform_action_with_benchmark      # 重定向原来的方法名到功能增强之后的方法


这种方式其实就是AOP的工作方式:ActionController::Base声明了perform_action方法,但它对benchmarking一无所知,只要把Benchmarking模块包含进去,就获得了benchmark的功能。Rails通过这种方式实现了低耦合,我们可以轻松地选择去除非必要的所有可选组件。Rails并非庞大,它是轻灵的,但我们需要了解它。


丰富

发展到今天RubyRails社区已经非常的活跃和强大。千万开源爱好者在不停地贡献着各种各样的Rails插件和Ruby库。

比如认证系统插件:restful_authentication,分页插件:will_paginate等等,这些插件的出现帮助我们节省了很多工作。并且,这些插件的实现都非常的优美,并不断地在优化和演进。
强大的社区支持,丰富的插件,让Rails开发变得更加容易。

优美

Rails的优美体现在很多地方,比如它本身就是一个REST风格的WEB架构。

REST就代表着优美么?这不足以让人信服,还是举个例子吧。

假定有一个InvoicesController,现在需要生成一个invoicepdf。我们可能会想到给controller添加一个叫做download_pdfaction

def download_pdf
invoice = Invoice.find(params[:id])
send_data(generate_pdf(invoice), :filename => ”#{invoice.no}.pdf”, :type => ”application/pdf”)
end


但从另一个角度看,其实pdf只是invoice这个资源的一种表现形式。而展现一个资源,更适合让show action来做。用REST风格实现invoidepdf下载:

def show
@invoice = Invoice.find(params[:id])
respond_to do |format|
format.html
format.pdf { render :pdf => generate_pdf(@invoice) }
end
end


用正确的方式做正确的事情,就是优美的体现。

反思

介绍了这么多Rails开发的优点,肯定有人不禁要提问:Rails开发难道就没有欠缺的地方么?

笔者也一样,在开发过程中不停地反思。比如为Rails创造最大声誉的快速开发,就值得谨慎看待。用Rails搭建的系统在代码量上确实少了很多,但纯粹用代码量来衡量开发效率是不准确的。有几点思考:

1. 当今程序员不再是纯文本编辑时代,强大的IDE极大地提高了程序员的开发效率。但作为一种动态语言,Ruby目前还很难享受到这种好处。

2. 对于任何语言,要写出简洁优美高效的代码,都需要精雕细琢。

3. 随着语言的进步,开发效率真正的瓶颈越来越多地体现在业务逻辑上,而不是代码的编写上,特别是对于复杂系统而言。

4. 从上文列举的那些例子中我们可以看到,Rails很美,但只有在正确使用它时才会很美。初学者可能会因为经验的缺乏落入一个又一个陷阱。不可否认,Rails的性能问题一直是大家担心的。但系统的性能问题真的是Rails本身引起的么?看似优美的代码,背后是否做着一些丑陋的事情?希望能在下篇讲述性能优化故事的文章中跟大家再次分享和探讨这些问题。


作者简介:

胡振波,ThoughtWorks公司咨询师。多年企业级应用开发经验,敏捷开发的一名忠诚实践者和思考者。关注编程技术、互联网发展。

(本文来自《程序员》杂志0910期)

转播到腾讯微博

----->立刻申请加入《程序员》杂志读者俱乐部,与杂志编辑直接交流,参与选题,优先投稿

3 Responses to “ThoughtWorks咨询师讲述Rails之美”

  1. Johnny 说道:

    “因为Rails本身是透明的,这首先是动态语言提供的好处。当需要了解任何一个方法的功能或者实现时,只需要跳到那个方法查看源代码即可。”
    这是什么逻辑呀?透明跟动态语言有什么关系?是想说跟开源有关系吧

  2. lear 说道:

    你说得天花乱坠,给我感觉rails就是垃圾,条条框框太多了,一点创造性的感觉都没有

  3. Day 说道:

    大师和平民的差距
    咱感觉就是不一样
    死的都能说成活的

请评论

preload preload preload
京ICP备06065162