重构 Rails 项目之最佳实践

March 04, 2013 Rails Refactor

春节前受 Terry 邀请帮助国内的一个公益项目 Re-education 做代码重构。开放课堂项目是由教育大发现社区发起，成都 ThoughtWorks，成都彩程设计公司，成都超有爱教育科技有限公司等一起合作开发和运营的教育公益网站，是一个提供给小学3-6年级师生设计和开展综合实践课的教育开放平台。项目代码放在 GitHub，采用 Ruby on Rails 作为开发框架。

很高兴我们 Fengche.co 团队能参与到这个公益项目的开发中，我相信这是个对社会很有价值的事情。征得发起方的同意，我把这次重构工作做成了一次在线秀，也正是因为这次这样的形式，和很多朋友直接在 Join.me 上交流了很多 Rails 项目重构方面的想法。通俗点说，重构就是对内要通过修改代码结构等方法让代码变得更美，提高可阅读性和可维护性，而__对外不改变__原来的行为，不做任何功能的修改。所以我们做重构要做好两点: 1) 一次只做一件事情，不能修改了多个地方后再做验证 2) 小步增量前进，路是一步一步走出来的。同时，为了保证重构的正确性，必须要测试保护，每一次小步修改都必须要保证集成测试仍然通过。之所以要保护集成测试而非单元测试，正是因为重构只改变内部结构，而不改变外部行为，所以，单元测试是可能失败的(其实概率也不高)，而集成测试是不允许失败的。基于 Re-education 的代码，这次重构主要涉及了 Controllers 和 Models 两个方面。有兴趣的朋友可以去 RailsCasts China 观看视频。

Rails 做为一个 Web 开发框架，几个哲学一直影响着它的发展，比如 CoC, DRY。而代码组织方式，则是按照 MVC 模式，推崇 “Skinny Controller, Fat Model”，把应用逻辑尽可能的放在 Models 中。

Skinny Controller, Fat Model

让我们来看最实际的例子，来自 Re-education 的代码。

```ruby class PublishersController < ApplicationController def create @publisher = Publisher.new params[:publisher]

# trigger validation
@publisher.valid?

unless simple_captcha_valid? then
  @publisher.errors.add :validation_code, "验证码有误"
end

if !(params[:password_copy].eql? @publisher.password) then
  @publisher.errors.add :password, "两次密码输入不一致"
end

if @publisher.errors.empty? then

  @publisher.password = Digest::MD5.hexdigest @publisher.password
  @publisher.save!

  session[:user_id] = @publisher.id
  redirect_to publisher_path(@publisher)
else
  p @publisher.errors
  render "new", :layout => true
end   end end ```

按照 “Skinny Controller, Fat Model” 的标准，这段代码有这么几个问题:

  1. action 代码量过长
  2. 有很多 @publisher 相关的逻辑判断。

从权责而言，Controller 负责的是接收 HTTP Request，并返回 HTTP Response。而具体如何处理和返回什么数据，则应该交由其他模块比如 Model/View 去完成，Controller 只需要当好控制器即可。所以，从这点上讲，如果一个 action 行数超过 10 行，那绝对已经构成了重构点。如果一个 action 对一个 model 变量引用了超过 3 次，也应该构成了重构点。下面是我重构后的代码。

```ruby class PublishersController < ApplicationController def create @publisher = Publisher.new params[:publisher]

if @publisher.save_with_captcha
  self.current_user = @publisher
  redirect_to publisher_path(@publisher)
else
  render "new"
end   end end

class Publisher < ActiveRecord::Base apply_simple_captcha :message => “验证码有误”

validates :password, :presence => { :message => “密码为必填写项” }, :confirmation => { :message => “两次密码输入不一致” }

attr_reader :password attr_accessor :password_confirmation

def password=(pass) @password = pass self.password_digest = encrypt_password(pass) unless pass.blank? end

private

def encrypt_password(pass) Digest::MD5.hexdigest(pass) end end ```

在上面的重构中，我主要遵循了两个方法。

  1. 把应该属于 Model 的逻辑从 Controller 移除，放入了 Model。
  2. 利用虚拟属性 password, password_confirmation 处理了本不属于 Publisher Schema 的逻辑。

关于简化 Controller，多利用 Model 方面的重构方法，Rails Best Practices 有不少不错的例子，也可以参考。

  1. Move code into model
  2. Add model virtual attribute
  3. Move finder to scope

Beyond Fat Model

对于项目初期而言，做好这两个基本就够了。但是，随着逻辑的增多，代码量不断增加，我们会发现 Models 开始变得臃肿，整体维护性开始降低。如果一个 Model 对象有效代码行超过了 100 行，我个人认为因为引起警觉了，要思考一下有没有重构点。一般而言，我们有下面几种方法。

[Concern](http://en.wikipedia.org/wiki/Concern_(computer_science)

Concern 其实也就是我们通常说的 Shared Mixin Module，也就是把 Controllers/Models 里面一些通用的应用逻辑抽象到一个 Module 里面做封装，我们约定叫它 Concern。而 Rails 4 已经内建支持 Concern, 也就是在创建新 Rails 项目的同时，会创建 app/models/concerns 和 app/controllers/concerns。大家可以看看 DHH 写的这篇博客 Put chubby models on a diet with concerns 和 Rails 4 的相关 commit。具体使用可以参照上面的博客和下面我们在 Fengche.co 里的实际例子。

```ruby module Membershipable extend ActiveSupport::Concern

included do has_many :memberships, as: :membershipable, dependent: :destroy has_many :users, through: :memberships after_create :create_owner_membership end

def add_user(user, admin = false) Membership.create(membershipable: self, user: user, admin: admin) end

def remove_user(user) memberships.find_by_user_id(user.id).try(:destroy) end

private

def create_owner_membership self.add_user(owner, true) after_create_owner_membership end

def after_create_owner_membership end end

class Project < ActiveRecord::Base include Membershipable end

class Account < ActiveRecord::Base include Membershipable end ```

通过上面的例子，可以看到 Project 和 Account 都可以拥有很多个用户，所以 Membershipable 是公共逻辑，可以抽象成 Concern 并在需要的类里面 include，达到了 DRY 的目的。

Delegation Pattern

Delegation Pattern 是另外一种重构 Models 的利器。所谓委托模式，也就是我们把一些本跟 Model 数据结构浅耦合的东西抽象成一个对象，然后把相关方法委托给这个对象，同样看看具体例子。

未重构前:

```ruby class User < ActiveRecord::Base has_one :user_profile

def birthday user_profile.try(:birthday) end

def timezone user_profile.try(:timezone) || 0 end

def hometown user_profile.try(:hometown) end end ```

当我们需要调用的 user_profile 属性越来越多的时候，会发现方法会不断增加。这个时候，通过 delegate, 我们可以把代码变得更加的简单。

```ruby class User < ActiveRecord::Base has_one :user_profile

delegate :birthday, :tomezone, :hometown, to: :profile

def profile self.user_profile || UserProfile.new(birthday: nil, timezone: 0, hometown: nil) end end ```

关于更多的如何在 Rails 里使用 delegate 的方法，参考官方文档 delegate module

Acts As XXX

相信大家对 acts-as-list，acts-as-tree 这些插件都不陌生，acts-as-xxx 系列其实跟 Concern 差不多，只是它有时不单单是一个 Module，而是一个拥有更多丰富功能的插件。这个方式在重构 Models 时也是非常的有用。还是举个例子。

```ruby module ActiveRecord module Acts #:nodoc: module Cache #:nodoc: def self.included(base) base.extend(ClassMethods) end

  module ClassMethods
    def acts_as_cache(options = { })
      klass = options[:class_name] || "#{self.name}Cache".constantize
      options[:delegate] ||= []

      class_eval <<-EOV
        def acts_as_cache_class
          ::#{klass}
        end

        after_commit :create_cache, :if => :persisted?
        after_commit :destroy_cache, on: :destroy

        if #{options[:delegate]}.any?
          delegate *#{options[:delegate]}, to: :cache
        end

        include ::ActiveRecord::Acts::Cache::InstanceMethods
      EOV
    end
  end

  module InstanceMethods
    def create_cache
      acts_as_cache_class.create(self)
    end

    def destroy_cache
      acts_as_cache_class.destroy(self)
    end

    def cache
      acts_as_cache_class.find_or_create_cache(self.id)
    end
  end
end   end end

class User < ActiveRecord::Base acts_as_cache end

class Project < ActiveRecord::Base acts_as_cache end ```

Beyond MVC

如果你在使用了这些方式重构后还是不喜欢代码结构，那么我觉得可能仅仅 MVC 三层就不能满足你需求了，我们需要更多的抽象，比如 Java 世界广而告之的 Service 层或者 Presenter 层。这个更多是个人习惯的问题，比如有些人认为应用逻辑(业务逻辑)不应该放在数据层(Model)，或者一个 Model 只应该管好他自己的事情，多个 Model 的融合需要另外的类来做代理。关于这些的争论已经属于意识形态的范畴，个人的观点是视需要而定，没必要一上来就进入 Service 或者 Presenter，保持代码的简单性，毕竟减少项目 Bugs 的永恒不变法就是没有代码。但是，一旦达到可适用范围，该引入时就引入。这里也给大家介绍一些我们在用的方法。

Service

之前已经提到 Controller 层应该只接受 HTTP Request，返回 HTTP Response，中间的处理部分应该交由其他部分。我们可以优先把这部分逻辑放在 Model 层处理。但是，Model 层本身从定义而言应该是只和数据打交道，而不应该过多涉及业务逻辑。这个时候我们就需要用到 Service 层。继续例子!

```ruby class ProjectHookService attr_reader :project, :data

def initialize(hook_params = {}) @project = Project.from_param(hook_params) @data = JSON.parse(hook_params[‘payload’]) end

def parse Prly.hook_services.each do |service| parser = service.new(@project, @data) if parser.parseable? parser.parse end end end

def parseable? @project.present? && @data.present? end end

class HooksController < ApplicationController def create service = ProjectHookService.new(params) if service.parseable? service.parse render nothing: true, status: 200 else render text: ‘Faled to parse the payload’, status: 403 end end end ```

如果大家仔细分析这段代码的话，会发现用 Service 是最好的方案，既不应该放在 Controller，又不适合放在 Model。如果你需要大量使用这种模式，可以考虑一下看看 Imperator 这个 Gem，算是 Rails 世界里对 Service Layer 实现比较好的库了。

Presenter

关于 Presenter，不得不提的是一个 Gem ActivePresenter，基本跟 ActiveRecord 的使用方法一样，如果项目到了一定规模比如有了非常多的 Models，那么可以关注一下 Presenter 模式，会是一个很不错的补充。

```ruby class SignupPresenter < ActivePresenter::Base presents :user, :account end

SignupPresenter.new(:user_login => ‘dingding’, :user_password => ‘123456’, :user_password_confirmation => ‘123456’, :account_subdomain => ‘pragmaticly’) ```

We’re good now

基本上上面是我在一个 Rails 项目里重构 Controller 和 Model 时会使用的几种方法，希望对你有用。Terry Tai 上周在他的博客里分享了他在重构方面的一些想法，也很有价值，推荐阅读。

Yedingding

关于我

技术创业者，系统架构师，GrowingIO 联合创始人，Teahour 主播。