Ruby China 社区重构节点

聊聊代码的复杂性

qiumaoyuan — Mon, 06 Jan 2025 11:23:00 +0800

回想起来，我的职业生涯有大半的时间都在有意无意的死磕这个问题。2016 年左右，开始觉得有必要写下来，因为总觉得不写下来的话，到该说的时候脑子里有许许多多的想法，临时却又说不出来什么。本文写于 2016-08-06，写得挺早，一直没有发在社区，放着好多年。现在看起来，来来回回也没改动多少，发出来大家随缘看看。

复杂从哪来

代码当中包含的复杂性，我分为两部分来看：业务逻辑本身的复杂性，和代码结构的复杂性。

对有点规模的系统程序来说，程序员本应该做的工作除了完成功能之外，就是消除代码结构额外的复杂性，让系统代码整体的结构趋向于跟业务逻辑在各个抽象层面上一致——即人们常说的：你所写的代码就是你想要表达的业务。

业务逻辑变得复杂，很多时候是业务发展的需要，程序员只有接受，并为业务提供支持。当然如果你身兼数职，可以以产品经理的身份在产品的角度优化一下，但这不是本文讨论的范围。抛开业务本身的复杂度，剩下的就是代码结构的复杂度了。

那么代码结构为什么总是变得越来越复杂呢？主要是跟程序员控制代码结构复杂度的能力有关。能力不足的程序员很容易经常犯些小毛病——例如在一个方法内部出现了临时变量，或者代码中出现了一个带了 2 个参数的方法（注 [^1]）——但他本身并没有意识到这是个问题。代码随着业务的变化和增加，这种小毛病就会越积累越多。

到了某一时刻，程序员会发现以前某些代码很难修改或者重用，多数情况下，能力不足的程序员这时候意识不到那些小毛病的存在，会很本能地选择对以前的代码做一种打补丁式的修改（比如多传个参数、多加个条件分支来处理一下特殊情况），或者干脆把代码大片复制出来做些小修改，而不是重新组织它——也就是我们常说的“重构”。

程序员们经常把“重构”这个词挂在嘴边，但遇到问题他们的选择要么是打补丁，要么干脆全部重写，真正做重构的真的很少。来复习一下“重构”一词的定义：在不改变代码外在行为的前提下，对代码进行修改，以改进程序的内部结构。这里的关键，是“改变内部结构”、“不改变外在行为”。理解了这一点之后，“重构把代码改出 bug”这样的认知错误自然就不存在了。

跑题了，言归正传。打个比方。想像一下，假设上面我所提到的程序员，在一开始经常犯的那些小错误，是在一根绳子上打了的一个小结。这种小结打多了之后，一整根绳子上就都是绳结。程序员对之前的问题代码打补丁的动作可以看成在之前的小结上打了一个更大的结，结上再打结……如此发展下去，最终系统必然是一团错综复杂的结。这时候，问题本身终于显而易见了——代码无比复杂，修改十分困难，但产生这问题的根本原因还是像迷一样难以被发现。

因为“解小结”的能力不足，所以才最终造成了这么一团大结。同样的因为“解小结”的能力一直不足，他们不知道应该从最外面的结开始解，解开一个结之后，才能再解这个结下面更多的小结（重构的过程真的是这样，你会发现首先要把代码用一种重构手法整理完之后，才能够再用另一种重构手法对解开的代码进行进一步的整理）。他们要么直接把这一团东西扔了重写一份——但是没有训练出“解小结”的能力的话，未来继续重新开始打结大概率是免不了的；要么继续痛苦地在这玩意上面继续打结。

代码之所以不容易写好，是因为许多错误的小决策往往要很久以后才能让人看到显而易见的问题。 没有即时的负面反馈，不够细心的人们就发现不了问题，“问题”对他们来说不存在，“改进”自然就无从谈起。 复杂难用的系统都是由小毛小病慢慢积累而来，最终才表现成为显而易见的大问题，但是每个小毛小病多数人看不见，临时用打补丁的方式不讲究地处理一下在他们看来似乎也没什么坏的影响。他们没有意识到 防微杜渐才是防止大病形成的唯一办法。 问题最终很明显的表现出来之后他们也往往不知道根源到底在哪里——其实根源都在之前做决定的每一步的细节里，没有一个单独存在的、明显的大问题（因为如果有，那早就被发现和解决了）——而正是因为这样，最终的问题往往都很难解决，你总是，总是会发现牵一发要动全身。

所以代码的版本越高越难以被读懂，除了业务变得复杂了以外，我觉得主要的原因在于此。

如何解决

提出问题，找到了原因，然后就得解决。

复杂是由简单组合而成的，巨复杂的代码结构问题本质上也都是些简单的问题组合成的。最终的那个复杂无比的问题不可能只用一种简单的手段一次性解决，只能针对组成整个大问题的那些小问题一个一个来解决。

那么解决这些不起眼的小问题的手段是什么？就是许多程序员不屑于练习的，被他们声称解决的问题过于简单，被他们认为无法用于解决实际项目当中超级复杂的系统问题的，同样不起眼的一个个重构手法。这些重构手法全在《重构》这本书后面的每一个示例里，我认为这本书的正确读法是把每个重构手法以及每一句示例代码都认真的阅读和理解一遍，搞清楚重构前的代码问题在哪，为什么那算得上是个问题，那个问题应该如何解决，解决这种问题本质上所运用的该编程语言的特性和原理是什么。

可能有人读了前五章之后，认为剩下的部分可以先放着，等遇到问题了再来读。但矛盾的地方在于，从第六章起之后的这部分容，很重要的一个作用就是训练程序员对各种细微 bad smell 的嗅觉，在大脑里对各种 bad smell 设置 trigger。未经训练的程序员在真遇到问题的时候，并不认为自己遇到了问题，因为那些问题就像这些重构手法一样，是如此的不起眼，最后自然也就不会再次打开这本《重构》。

当程序员控制代码结构复杂性的能力训练得足够好了，你会发现他写的代码模块职责清晰，大多数方法的代码行数真的不超过 10 行（这个数字用不同的 OOP 语言会有所不同）。系统里全是如此短小不互相纠缠的代码，还会有人觉得难读吗？

这里可能又可以引发出另一个讨论：到底什么样的代码才叫“直观”？什么是代码的可读性？似乎有不少程序员觉得层层调用的代码很不“直观”，把逻辑完全展开，平铺直叙的代码才叫“直观”。这背后隐含的问题是“到底什么是‘复杂’”，这又是另一个话题了。我知道其实很多人不习惯跟类似“什么是‘复杂’”这样看似简单、每个人好像都知道，但认真解释起来还是需要一些思考的概念死磕。

上面是我最近在思考的东西。

脚注

注 [^1]：并不是所有的临时变量都是不好的，也并不是所有参数多于 1 个的方法就是有问题的。这里是故意把“大量临时变量”中的“大量”给省去了，把“多个参数”写成了“2 个参数”。因为不在具体的上下文当中，“大量”和“多个”根本没个标准。至于如何判断，可以仔细阅读《重构》。

这里想要表达的是，所有的 bad smell 都是一种反模式，所谓“模式”就是很容易被人发现的一种有规律的定式，一旦遇到就要动脑子分析，和具体的规模（无论是“2 个”还是“很多个”，“5 行”还是“很多行”）无关。但很多程序员倾向于总结出非此即彼的固定标准，因为具体问题具体分析太费脑子，所以：临时变量既然不可能完全消除，就完全不需要消除；方法参数既然不可能永远不超过 1 个那就可以是 5, 6, 7, 8 甚至 10 多个；方法行数既然不能全部减少到 5 行那就说明 100 来行也是没问题的。最终失去了对 bad smell 的警觉。

而训练有素的程序员会把这些模式当作“触发器”，时时刻刻警觉着分析这些现象在当前的情况下到底算是个问题还是算正常情况。训练有素的程序员知道很多东西不是非此即彼，不可以一概而论，编程本身是一项脑力劳动很大程度上也是因此吧。

但是多数情况下我们似乎都倾向于追求和谐的统一，把编程变为体力劳动，只是因为那看起来更不需要思考。或者用有些人的话来说，“可以更容易招聘到不会思考的下等编码机器”，并称之为“软件工程”。只可惜采用这种“不需要思考”的方式写代码造成结果却往往是需要更多的思考，因为混乱的代码结构维护起来一定比条理清晰的代码费脑得多。

“复杂”说白了就是记忆负担。理解一件事物所需要保持的信息量超出人脑短期记忆能够应付的能力范围，就会让人觉得复杂。

后台系统重构 - 菜单同步

pinewong — Wed, 04 Aug 2021 08:13:21 +0800

需求

公司决定要使用前后端分离方式，重构一个维护了十余年的后台系统（原来是后端渲染方式）。由于持续过程较长，需要新旧系统并存一段时间。这个并存希望对使用者透明，因此我们把新系统界面结构弄的跟旧系统很相似，且我们要实现两个系统菜单完全一致。

要做到完全一致，首先需要将旧系统菜单抽离出来，改成可配置形式。其次因为新系统是前端渲染形式，所以新系统菜单需要通过 API 获取。接下来详细介绍具体实现的要点，实现代码以框架 Rails 5 和 Vue.js 2 举例，实际上其他框架大同小异。

请求路由定义

首先是路由定义。路由定义每个系统单独定义自己的功能，假如现在总共有三个功能，其中一个功能已经重构到了新系统内。

1、旧系统（Rails）还剩下两个路由：

# config/routes.rb

Rails.application.routes.draw do
  get "function-A1" => "function_a1#index"
  get "function-A2" => "function_a2#index"
end

2、新系统（Vue.js）增加一个路由：

// src/configs/routes.js

const routes = [  
  {
    path: '/function-B1',
    component: () => import('@/pages/function_b1'),
  },
]

菜单改成可配置化

然后是菜单配置问题。配置形式采用 yaml 格式，使用最简单的树形结构，配置内容尽可能的少。

1、配置菜单：

# config/menus.yml

- name: 菜单A
  icon_old: icon-a
  icon_new: mdi-a
  children:
    - name: 菜单A1
      link: /function-A1
    - name: 菜单A2
      link: /function-A2
- name: 菜单B
  icon_old: icon-b
  icon_new: mdi-b
  children:
    - name: 菜单B1
    - link: /frontend/function-B1
# ...

这里假定 /frontend 开头的连接，会使用新系统（Vue.js）进行服务（这里需要配置代理和 Nginx，此文先不展开），其他情况使用旧系统（Rails）进行服务。

2、加载菜单配置文件：

# config/initializers/config_menus.rb

file_dir = Rails.root.join('config', 'menus.yml')
Rails.configuration.menus = YAML.load_file(file_dir)
# 之后可在程序中这样获取：Rails.configuration.menus

（进阶一）其中我们可能要经常要在菜单配置中使用 Rails Routes Helper 方法，可以改用如下加载方式：

# config/initializers/config_menus.rb

Rails.configuration.after_initialize do |application|
  # 开发环境此时路由数据依然为空，需要主动 reload
  # https://stackoverflow.com/a/8707687
  application.reload_routes!

  file = File.read(Rails.root.join('config', 'menus.yml'))
  # yaml 配置中，可以用 <%= xxx_path %> 方法
  bind = application.routes.url_helpers.instance_eval { binding }
  application.config.menus = YAML.load(ERB.new(file).result(bind))
end

（进阶二）树形结构不好通过子节点取父节点，这里通过程序给菜单自动添加一个 tree_nodes 属性，使得后续用起来更方便：

# config/initializers/config_menus.rb

file_dir = Rails.root.join('config', 'menus.yml')
Rails.configuration.menus = YAML.load_file(file_dir)
# 菜单A的 tree_nodes 为: [1], 菜单A1: [1, 1], 菜单A2: [1, 2], 菜单B: [2]
add_tree_nodes = lambda { |menus, parent_tree_nodes = []|
  menus.each_with_index do |menu, index|
    tree_nodes = parent_tree_nodes + [index + 1]
    menu.merge!("tree_nodes" => tree_nodes)
    add_tree_nodes.call(menu['children'], tree_nodes) if menu['children'].present?
  end
}
add_tree_nodes.call(Rails.configuration.menus)

旧系统菜单渲染

旧系统是后端渲染方式，可以直接取到配置并渲染。渲染采用递归形式渲染，下面是一些核心方法。

1、在布局里渲染菜单：

# app/views/layouts/application.html.erb

# 菜单栏
<%= render_menus(Rails.configuration.menus) %>

2、菜单渲染核心方法（UI 框架为 Bootstrap 2）：

# app/helpers/menus_helper.rb

module MenuHelper
  def render_menus(menus, depth = 1)
    doms = menus.map do |menu|
      if menu['children']
        <<~HTML
          # 这里假设 open 样式会让父菜单打开折叠
          <li class="#{'open' if menu_active?(menu, depth)}">
            <a href="#" class="dropdown-toggle">
              <i class="#{menu['icon_old'] || 'icon-double-angle-right'}"></i>
              <span class="menu-text">#{menu['name']}</span>
              <b class="arrow icon-angle-down"></b>
            </a>
            <ul class="submenu">
              #{render_menus(menu['children'], depth + 1)}
            </ul>
          </li>
        HTML
      else
        <<~HTML
          # 这里假设 active 样式会让子菜单高亮
          <li class="#{'active' if menu_active?(menu, depth)}">
            <a href="#{menu['link']}">
              <i class="#{menu['icon_old'] || 'icon-double-angle-right'}"></i>
              <span class="menu-text">#{menu['name']}</span>
            </a>
          </li>
        HTML
      end
    end
    doms.join.html_safe
  end

  private

  # 这里用到了上面菜单配置进阶二中的 tree_nodes 属性，如果不用，也可以用其他方式解决
  def menu_active?(menu, depth)
    current_active_menu&.dig('tree_nodes')&.first(depth) == menu['tree_nodes']
  end

  # 深度遍历，获取第一个命中的菜单（命中算法这里简单使用当前 url 的 path，实际情况可能更复杂，这里不展开讨论）
  def current_active_menu(menus = nil)
    @current_active_menu ||= begin
      menus ||= Rails.configuration.menus
      menus.each do |menu|
        if menu['children']
          active_menu = current_active_menu(menu['children'])
          return active_menu if active_menu
        elsif request.path == menu['link']
          return menu
        end
      end
      nil
    end
  end
end

新系统菜单渲染

新系统是前端渲染形式，除了获取菜单数据方式需要通过 API 形式，其他跟上面逻辑大同小异，大部分就是 Ruby 代码改 JS 代码。

1、首先定义后端菜单获取的 API：

# app/controllers/api/menus_controller.rb

module Api
  class MenusController < ApplicationController
    def index
      render json: { menus: Rails.configuration.menus }
    end
  end
end

2、然后是前端布局中渲染菜单：

<!-- src/layouts/index.vue -->

<template>
  <Menus :menus="menus" :currentActiveMenu="currentActiveMenu" />
</template>
<script>
import Menus from '@/components/Menus'
export default {
  components: {
    Menus,
  },
  data: function () {
    return {
      menus: [],
      currentActiveMenu: null,
    }
  },
  mounted () {
    axios
      .get('/api/menus.json')
      .then(res => {
        this.menus = res.data.menus
        // 根据当前访问 url，设置匹配到的菜单，后续高亮这个菜单要用
        this.setCurrentActiveMenu(this.menus)
      })
  },
  method: {
    setCurrentActiveMenu (menus) {
      menus.forEach(menu => {
        if (menu.children) {
          const activeMenu = this.setCurrentActiveMenu(menu.children)
          if (activeMenu) { this.currentActiveMenu = activeMenu }
        } else if (location.pathname === menu.link) {
          this.currentActiveMenu = menu
        }
      })
    },
  },
</script>

3、最后是完成核心菜单组件（UI 框架为 Vuetify 2）：

<!-- src/components/Menus.vue -->

<template>
  <v-list>
    <template v-for="menu in menus">
      <v-list-group
        v-if="menu.children"
        :key="menu.name"
        :sub-group="isSubmenu"
        :value="isMenuActive(menu)"
      >
        <template v-slot:activator>
          <v-list-item-icon v-if="!isSubmenu">
            <v-icon v-text="menu.icon_new || 'mdi-notification-clear-all'" />
          </v-list-item-icon>
          <v-list-item-content>
            <v-list-item-title v-text="menu.name" />
          </v-list-item-content>
        </template>
        <Menus :menus="menu.children" :currentActiveMenu="currentActiveMenu" :depth="depth + 1" />
      </v-list-group>
      <v-list-item
        v-else
        :key="menu.name"
        :href="menu.link"
        :class="{ 'v-list-item--active': isMenuActive(menu) }"
      >
        <v-list-item-icon v-if="!isSubmenu">
          <v-icon v-text="menu.icon_new || 'mdi-notification-clear-all'" />
        </v-list-item-icon>
        <v-list-item-content>
          <v-list-item-title v-text="menu.name" />
        </v-list-item-content>
      </v-list-item>
    </template>
  </v-list>
</template>

<script>
  export default {
    name: 'Menus', // 采用递归组件形式，需要配置组件名称
    props: {
      menus: { type: Array, required: true },
      currentActiveMenu: { type: Object },
      depth: { type: Number, default: 1 },
    },
    methods: {
      isMenuActive(menu) {
        if (this.currentActiveMenu) {
          return this.currentActiveMenu.tree_nodes.slice(0, this.depth).join(',') === menu.tree_nodes.join(',')
        } else {
          return false
        }
      },
    },
    computed: {
      isSubmenu () {
        return this.depth !== 1
      },
    },
  }
</script>

其他

以上是最小核心解决方式，后面要在实际项目中用起来，还要处理菜单是否可见、菜单是否新窗口打开、菜单是否有权限等一系列问题，大部分可以在配置文件中增加配置项解决。

其实将系统菜单配置到 menus.yml 中才是最花时间的，手动整理了 1000 多行 -_-

目前程序已经开发了一年，想要有 2.0 版本的规划，怎么去做设计书

tingsen — Fri, 03 Jan 2020 11:11:17 +0800

一个多商户商城的哦 saas 系统，我是半路接手的，目前有一些底层的数据库结构不合理，限制了功能的开发进度，领导想要重构项目，开发一个 2.0 版本。一遍以后能够快速迭代，模块开发。目前已经有 200 多个付费用户，需要考虑老数据的迁移。上面的意思让出一个设计说明书，不知道从哪里下手，谁能给个思路。

一款成功的全球服游戏该如何进行架构选型与设计

ucloudcn — Mon, 23 Jul 2018 13:58:49 +0800

全球服游戏如今正在成为出海游戏的主要考虑模式，跨国对战、全球通服打破国界的限制，将不同地区不同语言的玩家放在一起合作/竞技，成功吸引了大量玩家的关注，并逐渐成为主流的游戏玩法。

游戏厂商们也在尝试采用一地部署多地覆盖、全球逐步宣发的模式进行第一款全球服游戏的发行试点及成本控制。文章主要针对全球服和出海游戏的特性优势、架构布局、网络规划、实用技术等几个方面进行探讨。

本文主要观点：

(1) 微服务是主流，模块化架构易于扩容以及维护，微服务 + 自动化的业务架构对于全球服游戏来说几乎是必然的选择；

(2) 架构高度自动化，自动注册/剔除保证可用性；

(3) 帧同步+UDP 特性，高性能传输和带宽成本控制（对战类游戏要求较为突出）；

(4) 核心架构集中部署为主，全球网络优化覆盖玩家；

(5) 游戏代码的关键帧及预判设计关系到游戏对网络延迟的兼容性。

为什么要微服务和自动化？

原因一：全球服游戏多为逻辑服或无区服概念的通服、对战类游戏。为了保证游戏性和全球化的特点，保证匹配和游戏世界玩家的多元化，传统意义上的区服架构和跨服对战模式并不适配，以皇室战争、列王纷争等为例的一众匹配对战游戏便是其中的代表。

原因二：全球服游戏要求承载全球玩家的涌入，及时发现负载瓶颈并扩容是一个必然的要求，模块化拆分架构之后可以灵活的针对不同活动、玩家特性增加对应的业务服务器，并通过自动注册机制实现快速扩容。

整个架构采用注册管理 + 自动化之后，可以通过研发脚本或者通行的管理工具，甚至 Docker 的 K8S 来实现业务宕机的自动恢复和容灾、负载突发的自动扩容，这可以极大的降低运维成本，并对于业务健壮性进行极大的提升。

对于游戏服务的自动注册机制，在项目早期，受限于研发实力或者工期，开发者一般会选择 ZooKeeper 进行管理维护，但是在实际运行中由于 ZooKeeper 自身较重的功能实现、二次开发及 bug 处理的复杂度，很多用户会将其替换为自主研发实现的轻量级 RPC 自动注册服务。实际情况要具体视研发能力而定，此外 GRPC 也有不少的支持者。

帧同步技术和 UDP 传输协议的使用

关于帧同步主要针对对战类游戏，对于 RPG 世界或者卡牌类游戏也有一定参考意义，用户使用帧同步主要在于三点：1、全球同步效率；2、服务端压力缓解；3、全球化大流量的成本控制。

以往有过这样的情况，用户在全球服游戏逐步宣发、对应国家客户端上线的过程中，遇到跨国专线成本问题无法承担的问题，最终无奈选择降级服务采用特殊优化过的外网出口覆盖的案例。

而选择使用 UDP 传输而非 TCP 传输主要考虑到对战要求的实时性，TCP 自身的重传逻辑已经无法满足全球化（对战）游戏的网络保障要求，通过自主实现 UDP 重传，甚至是报文同时重复发送的逻辑，来保证游戏数据包最终的抵达成功率。

关于最核心的全球服模式上，我的总结是：先集中再分布。

以当前大部分游戏的框架，如卡牌对战、RPG 世界等完全可以通过集中部署 + 网络调优的方式实现，当前全球双向延迟一般在 300ms 以内，而一般人的反应时间一般在 300ms 左右，故网络延迟对于玩家的感知非常微小，大部分游戏都可以集中部署并且不牺牲玩家游戏体验。同时集中部署的另一个优势是对于架构复杂度的降低，维护便捷度的提升，对于成本控制及玩家数据统计也会方便很多。

图一：集中部署全球服架构

什么情况下考虑“再分布”呢？首先，游戏是房间类的对战游戏，其次游戏对于网络延迟极敏感（FPS 类），最后重要的点是，游戏架构采取的是对战前缓存预热数据、对战结束后写入的异步模式。

图二：分布式部署全球服架构

下图为对战游戏的基础架构，通过该部署模式要点为：

（1）平台操作仍然集中化部署玩家统一访问，如日常操作、装备购买等延迟不敏感操作；（2）对战房间分布于全球各个数据中心，而当玩家需要对战、进行匹配分房时，通过算法调度到相对大多数用户最近的节点；

（3）节点提前预取相关用户数据，对战产生的全部数据统计由本地进行交互处理，并在对战结束后集中上传至中心数据节点。

图三：对战游戏基础架构

该方案在对战网络延迟和数据一致性上进行了保证，但是相对架构会更为复杂，实际落地过程中需要较好的配合和较深的维护经验。

那么，当前的分布式数据库解决方案是否能够解决全球服数据一致性的问题？实际上，为了保证数据一致性，这里以 TiDB 为例，暂不支持超过 30ms 的集群内部延迟。而且即使强行部署，集群内部的高延迟会严重影响 QPS 性能。在当前的技术环境下，全球分布式数据库最好的代表者应该是区块链技术，不过性能是绝对无法满足大部分游戏使用的，即使是仅有 21 个核心节点的 EOS，其极限 QPS 也远逊于普通配置的集中数据库。

游戏设计和网络延迟的关系

游戏设计初期必然要对当前全球网络环境有一个初步了解，这点之前也有提到，基本上当前物理链路的双向延迟为 300ms 内，但是考虑到无线信号不稳定、传统 3G 网络性能等原因，极端情况可能达 500-1000ms 甚至更高的情况，游戏必须为此进行一定取舍，早期帧同步游戏会因为网络最差的玩家造成整个战局的卡顿，而随着技术的发展，乐观锁已经通过舍弃低网络质量玩家的部分数据包来保证全球的游戏体验。

图四：简单全球网络数据

这边先不说延迟本身，聊下限制网络延迟的客观因素和数据：地球周长是 40076 千米 (赤道)，光速恒定 299792458 米／秒（真空），而网络当前主要是光纤传输，在物理速度和传输介质没有突破性进展的情况下绕地球一周需要近 150ms，而实际网络光缆不一定完全直线，中间设备转发也会造成延迟开销，按照实际网络质量评估的话，中国全国覆盖一般在 100ms（包括偏远地区）。

我们之前遇到一位用户，研发要求全球服在 60ms 的延迟以内。按照正常情况，60ms 一般可以勉强覆盖北上广三地热门地区。但是要全球服的情况下会比较捉襟见肘，这种情况下，建议做成跨国区域服的模式。

另外关于国际出口的情况，以中国为例，从我们的监控情况看，常规出口的可用率并不乐观，而我们亚太数据中心接入的电信 CN2 精品网可以做到不错的稳定性保证（也的确有全球服游戏通过此出口传输），但是并不能做到非常完美的 SLA，不定期也会发生拥塞和抖动。而且这个问题并不是中国特例，台湾地区、俄罗斯、印尼、印度部分邦都存在有一定的跨国出口问题，需要通过外网接入点选择或者产品解决方案如 UCloud PathX 解决方案进行网络优化。

图五：PathX 案例视图

所以在做一个全球服的项目之前，可以先做调研、和云厂商或者同行多聊聊，基于这些信息，在关键帧和乐观锁的时间制定、游戏内部预判及同步机制的设计上会更有把握。

杂谈拓展：区块链游戏

区块链游戏是一种新兴的游戏模式，但是本质上是依托于以太坊或者其他共识模式的链实现的玩法，当前市场上的游戏主要分两类：1、纯区块链游戏；2、装备或搜集元素上链。

前者主要以以太猫为代表，核心是收集、养成类游戏，随着部分市场关注赋予了部分商业属性。后者则是融合了区块链元素在其内部，附加了很多其他玩法，诸如集换式卡牌等等。

区块链行业还在摸索阶段，共识算法、共同监督、不可否认性是其核心特质，但性能较低、需要支付 GAS 等也是其短板，现在作相关评论还比较早，如果有兴趣的话，可以钻研下相关共识技术，对于各种链、共识技术有一个认知后，再根据自己的游戏模式选择一个适合的场景。

一般来说区块链游戏和链本身是相互依存的，如果链自身出现问题也会影响到游戏，可以说链是基础支撑，这个在选择的时候建议慎重考虑。我们也在探索相关的技术方向实践，并同公有云进行结合。7 月 21 号 UCan 下午茶成都站——“游戏出海，那些弯和那些坑”主题沙龙上，沈皓也会在现场深入分享出海游戏全球服架构及解决方案，感兴趣的读者可以关注沙龙后续技术内容。

作者介绍

沈皓：UCloud PathX 产品早期方案设计者之一，深耕全球服游戏领域，曾全面负责多个知名游戏出海项目的全球/跨国业务对接、部署及落地。对于 MOBA、RTS、FPS 等各类游戏的出海全球化的需求、难点、架构实现等深入分析并有独到见解。

更多内容请微信关注“UCloud 技术公告牌”查看。

TestProf

victor — Fri, 06 Jul 2018 09:58:30 +0800

TestProf 收集了一堆测试分析和性能优化相关的工具。

https://test-prof.evilmartians.io/#/?id=testprof

反模式之虚拟模型模式及其应用

jasl — Wed, 20 Jun 2018 17:18:43 +0800

前言

本篇来自去年在公司内部的分享的提纲，一直静静躺在我的网盘里。

模型在 Rails 已经被潜移默化的特指继承自 ActiveRecord 的类或者说是有实体表对应的模型类，而实际工作中，特别是在数据展示层，表单、页面上的数据渲染，并不一定完全的跟数据模型对应，所以实践中也会为表单建模，或者使用 reform 等 gem，这边是虚拟模型的最初用途——静态的为特定需求建立模型。

在复杂的信息系统中，存在定制字段的情况：如金数据这样的问卷系统；复杂门类的电商系统中为不同品类的商品定义不同的商品参数；在企业信息系统中，针对档案、工作流需定义字段。这些场景的共同点是：数据是有结构的、数据是有类型的、数据是有约束的。建模恰恰是解决这类问题的最佳手段，而难点在于设计一套动态的建模机制。

而动态是 Ruby 最擅长的，所以，我发明了虚拟模型模式来解决动态定义数据结构场景的问题。

我也相信，Ruby 和 Rails 在信息系统的开发上大有可为，从很多媒体的文章看，这个企业 SaaS 在国内仍是蓝海。希望这个技巧能够让基于 Rails 的系统在交付效率和功能性上拥有优势。

本篇只涉及原理的介绍。

应用

动态定义数据结构的场景，如表单
无查询需要，数据结构复杂，在关系型数据库上难以建模或维护数据，如配置（典型的，表单字段不同的字段类型的配置）

反模式

反模式是一种试图解决问题的方法，但通常会同时引发别的问题。反模式虽以不同的形式被广泛实践，但这其中仍存在一定的共通性。

...

规则总有例外。在某些情况下，本来认为是反模式的设计却可能是合理的，或者说至少是所有的方案中最合理的。

—— 摘自《SQL 反模式》：引言

前置知识

ActiveModel

http://guides.rubyonrails.org/active_model_basics.html

本质是一组接口，定义了 Rails 的模型应具有的行为以及和视图、控制器的交互规范。从 Rails 5 开始，越来越多的 ActiveRecord 的功能逐步移动到 ActiveModel 当中。

（个人观点）代码的设计的可改进空间很大，由于 ActiveRecord 和 Arel 强耦合以致部分移动到 AM 的模块在 AR 中又被较大规模的重写了一遍，没有继承或复用。

属性（Attribute）的赋值、读取接口
模型的回调事件声明（回调的注册和触发属于 ActiveSupport）
视图和控制器的一些调用约定（例：render @person render 通过对象的 to_partial_path 方法来确定使用哪个视图文件进行渲染）
脏属性追踪
数据验证和验证错误信息的容器
SecurePassword
序列化的基础支持：基于属性的读取接口，返回可用于序列化的 Hash 对象
I18n
类型转换（小技巧：ActiveModel::Type.lookup(:boolean).cast('0') #=> false）

虚拟模型

实现了 ActiveModel 接口的 Ruby 对象，通常用来做 Presenter、Form Object

https://github.com/makandra/active_type https://github.com/solnic/virtus

ActiveRecord::Attributes::ClassMethods#attribute

http://api.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html#method-i-define_attribute

用于显式声明属性，类似 Mongoid 的 field，需要指明属性的类型，可在赋值时自动进行类型转换。

在 ActiveRecord 中，属性的存储分为三个层次：

来自数据库
来自用户（类型转换的）
来自用户（未经类型转换）

有修饰符（modifier）机制，部分（其实只有 pg）数据库适配器会实现修饰符，如 pg 增加了 array 修饰符，使得属性可以变成强类型的数组字段！

也可以指定默认值，虽然可以使用 proc 却执行 proc 时不包含上下文，作用很受限。

ActiveRecord::AttributeMethods::Serialization#serialize

http://api.rubyonrails.org/v5.1/classes/ActiveRecord/AttributeMethods/Serialization/ClassMethods.html#method-i-serialize

也是一种反模式
将 Ruby 对象 marshaling 后存入数据库字段中，易于简化如 Array、Hash 等类型数据的持久化
在一些知名开源项目中有广泛应用，Redmine、Gitlab 等

考虑：有几种固定类型的商品，不同类型的商品有不同的商品参数

一种可行的传统做法

可以为不同类型的商品的商品参数分别建模（表），然后通过 STI 区分不同类型的商品并增加相应的关联。

好处：

关系型数据库的标准使用方式
标准的 Rails 开发体验，实现难度极低

缺点：

更改商品参数的时候同时需要修改表结构，进行数据迁移

另一种可行的做法：AR#serialize + 虚拟模型

在商品表上增加 text 类型的 spec 列
为不同类型的商品的商品参数分别建立虚拟模型
为这些虚拟模型实现 AR serialize 约定的 dump 和 load 即序列化和反序列化方法
在不同类型商品的模型中分别声明 serialize :spec, 对应的商品参数虚拟模型类

比较

优点：

节省了查询
MongoDB 的 schema-less 的开发体验

缺点：

虚拟模型中的字段无法用于查询

可以考虑使用使用现代数据库的 NoSQL 数据类型存储（如 hstore、json）、使用 elastic 或者索引表

再考虑：商品类型由运营管理，商品参数也由运营设置

如何设计来支撑运营能够自由创建商品类型并且可以为商品类型定制商品参数？

大体上

我们需要一个模型来记录运营输入的商品参数的字段定义
我们需要想办法存储运营为商品添加的额外的商品参数数据

细节上

商品字段的参数的校验方式要如何定义和存储？
数据提交后要如何进行校验？
要如何提取这些数据以便使用？
商品类型的参数变更，已有数据要如何处理？

同时兼顾

可维护性
扩展性（新的类型的字段、验证规则等）
易用性

传统做法

开源项目中的实现，可参考 Redmine。

CustomField(id: integer, name: string, field_format: string, ...)

CustomValue(id: integer, customized_type: string, customized_id: integer, custom_field_id: integer, value: text)

模型设计清晰易懂，但是表单的渲染、字段的验证、数据提交的处理都要实现，相关代码将近 2000 行。

技巧：动态模型类生成

AM、AR 提供的 DSL，都是以公开的类方法的形式混入模型类的，也就是说可以通过 User.validates :name, presence: true 的写法为 User 模型增加新的验证
同理可以在运行时为模型增加新的行为（字段、回调等）
通过 class 关键字定义的类（例如定义在 app/models 目录里的模型类）的生命周期是跟 APP 的生命周期一致的，故不可以直接操作他们
Ruby 的 Class.new 方法可以实现动态创建类型，其形参为基类，于是如下代码是可行的

new_user_class = Class.new(User)
new_user_class.validates :name, presence: true

将得到一个匿名的 User 的子类，对其修改将不会污染 User

另一种可行的做法：动态虚拟模型生成

和传统做法一样，我们需要一个模型来记录运营输入的商品参数的字段定义，然后，我们将这些定义转换成虚拟模型类

model = Class.new(VirtualModel::Base)
custom_fields.each do |field|
  model.attribute field.name, field.field_format
  # model.validates
end

便可得到标准的 Rails 模型，渲染也很简单

<%= form_for @instance do |f| %>
  <% custom_fields.each do |field| %>
    <% case field.field_type %>
    <% when "text" %>
      <% f.text_field field.name %>
    <%# ... %>
    <% end %>
  <% end %>
<% end %>

坑：model_name

Class.new 生成的匿名类 name 方法返回值为 nil，而 ActiveModel::Naming 即 model.model_name 依赖这个方法的返回值，为 nil 时，将会产生异常，所以需要在虚拟模型的基类上覆写这个方法

示例：FormCore

https://github.com/rails-engine/form_core

dummy 应用包含了：

虚拟模型基类的封装
表单和表单字段的模型设计
实现了各种字段类型
- 多种常见的字段类型：文本、整形、Decimal、日期、时间等
- 复杂字段类型：单选、多选等
- 外部数据源字段
- 嵌套子表单
字段类型支持配置验证器，验证器通过 AOP 实现代码复用
字段类型支持配置
字段的配置存储易于进行数据迁移
可配置的表单结果的序列化方式
定义了标准的虚拟模型生成方式
虚拟模型的服务器端渲染参考实现
...

DuckRecord

https://github.com/jasl-lab/duck_record

Fork 自 ActiveRecord 5.0，外科手术式的剥离了 Arel，并引入了类似 Mongoid 的 embeds_one、embeds_many DSL 用于支持嵌套子模型，从 pg 中剥离了类型的 array modifier，用于支撑多重选择

其他应用：RoleCore

https://github.com/rails-engine/role_core

介绍见：https://ruby-china.org/topics/36065

将现有的 model 的 pk 从 bigint 的 id 变为 uuid, 是放在 migration 还是 task 中比较好.

zengfengbo — Wed, 29 Nov 2017 15:34:40 +0800

步骤如下

找到对应的 model(M), 添加 uuid 字段，生成 uuid(Uniq).
找到以 M.id 为外键的其他 model(FM) 所有字段，添加对应的对应的 m_uuid(Uniq).
根据之前的 FK 关系，同步 m_uuid = uuid.
解除之前按 id 建立的外键依赖，添加 uuid 之间的外键依赖。
重命名，id->id2, 所有 m_id->m_id2, uuid->id, 所有 m_uuid->m_id.
可选，删除 id2, 和 m_id2.

Rails 并发发送请求问题请教

zealinux — Wed, 29 Nov 2017 11:14:58 +0800

场景是这样的：

action 里需要发送两个请求外部的服务，然后把两次结果组装起来返回。

现在是顺序进行访问的，其实这两个服务其实是可以并行访问，

这样 action 请求时间会节省到其中一个最长的那次请求响应时间。

现在应该怎么处理？

server：puma http client: faraday

如何从 MongoDB 迁移到 MySQL

Draveness — Mon, 23 Oct 2017 21:06:10 +0800

最近的一个多月时间其实都在做数据库的迁移工作，我目前在开发的项目其实在上古时代是使用 MySQL 作为主要数据库的，后来由于一些业务上的原因从 MySQL 迁移到了 MongoDB，使用了几个月的时间后，由于数据库服务非常不稳定，再加上无人看管，同时 MongoDB 本身就是无 Schema 的数据库，最后导致数据库的脏数据问题非常严重。目前团队的成员没有较为丰富的 Rails 开发经验，所以还是希望使用 ActiveRecord 加上 Migration 的方式对数据进行一些强限制，保证数据库中数据的合法。

文中会介绍作者在迁移数据库的过程中遇到的一些问题，并为各位读者提供需要停机迁移数据库的可行方案，如果需要不停机迁移数据库还是需要别的方案来解决，在这里提供的方案用于百万数据量的 MongoDB，预计的停机时间在两小时左右，如果数据量在千万级别以上，过长的停机时间可能是无法接受的，应该设计不停机的迁移方案；无论如何，作者希望这篇文章能够给想要做数据库迁移的开发者带来一些思路，少走一些坑。

从关系到文档

虽然这篇文章的重点是从 MongoDB 迁移到 MySQL，但是作者还是想简单提一下从 MySQL 到 MongoDB 的迁移，如果我们仅仅是将 MySQL 中的全部数据导入到 MongoDB 中其实是一间比较简单的事情，其中最重要的原因就是 MySQL 支持的数据类型是 MongoDB 的子集：

在迁移的过程中可以将 MySQL 中的全部数据以 csv 的格式导出，然后再将所有 csv 格式的数据使用 mongoimport 全部导入到 MongoDB 中：

$ mysqldump -u<username> -p<password> \
    -T <output_directory> \
    --fields-terminated-by ',' \
    --fields-enclosed-by '\"' \
    --fields-escaped-by '\' \
    --no-create-info <database_name>

$ mongoimport --db <database_name> --collection <collection_name> \
    --type csv \
    --file <data.csv> \
    --headerline

虽然整个过程看起来只需要两个命令非常简单，但是等到你真要去做的时候你会遇到非常多的问题，作者没有过从 MySQL 或者其他关系型数据库迁移到 MongoDB 的经验，但是 Google 上相关的资料特别多，所以这总是一个有无数前人踩过坑的问题，而前人的经验也能够帮助我们节省很多时间。

使用 csv 的方式导出数据在绝大多数的情况都不会出现问题，但是如果数据库中的某些文档中存储的是富文本，那么虽然在导出数据时不会出现问题，最终导入时可能出现一些比较奇怪的错误。

从文档到关系

相比于从 MySQL 到 MongoDB 的迁移，反向的迁移就麻烦了不止一倍，这主要是因为 MongoDB 中的很多数据类型和集合之间的关系在 MySQL 中都并不存在，比如嵌入式的数据结构、数组和哈希等集合类型、多对多关系的实现，很多的问题都不是仅仅能通过数据上的迁移解决的，我们需要在对数据进行迁移之前先对部分数据结构进行重构，本文中的后半部分会介绍需要处理的数据结构和逻辑。

当我们准备将数据库彻底迁移到 MySQL 之前，需要做一些准备工作，将最后迁移所需要的工作尽可能地减少，保证停机的时间不会太长，准备工作的目标就是尽量消灭工程中复杂的数据结构。

数据的预处理

在进行迁移之前要做很多准备工作，第一件事情是要把所有嵌入的数据结构改成非嵌入式的数据结构：

也就是把所有 embeds_many 和 embeds_one 的关系都改成 has_many 和 has_one，同时将 embedded_in 都替换成 belongs_to，同时我们需要将工程中对应的测试都改成这种引用的关系，然而只改变代码中的关系并没有真正改变 MongoDB 中的数据。

def embeds_many_to_has_many(parent, child)
  child_key_name = child.to_s.underscore.pluralize
  parent.collection.find({}).each do |parent_document|
    next unless parent_document[child_key_name]
    parent_document[child_key_name].each do |child_document|
      new_child = child_document.merge "#{parent.to_s.underscore}_id": parent_document['_id']
      child.collection.insert_one new_child
    end
  end
  parent.all.unset(child_key_name.to_sym)
end

embeds_many_to_has_many(Person, Address)

我们可以使用上述的代码将关系为嵌入的模型都转换成引用，拍平所有复杂的数据关系，这段代码的运行时间与嵌入关系中的两个模型的数量有关，需要注意的是，MongoDB 中嵌入模型的数据可能因为某些原因出现相同的 _id 在插入时会发生冲突导致崩溃，你可以对 insert_one 使用 resuce 来保证这段代码的运行不会因为上述原因而停止。

通过这段代码我们就可以轻松将原有的嵌入关系全部展开变成引用的关系，将嵌入的关系变成引用除了做这两个改变之外，不需要做其他的事情，无论是数据的查询还是模型的创建都不需要改变代码的实现，不过记得为子模型中父模型的外键添加索引，否则会导致父模型在获取自己持有的全部子模型时造成全表扫描：

class Comment
  include Mongoid::Document
  index post_id: 1
  belongs_to :post
end

在处理了 MongoDB 中独有的嵌入式关系之后，我们就需要解决一些复杂的集合类型了，比如数组和哈希，如果我们使用 MySQL5.7 或者 PostgreSQL 的话，其实并不需要对他们进行处理，因为最新版本的 MySQL 和 PostgreSQL 已经提供了对 JSON 的支持，不过作者还是将项目中的数组和哈希都变成了常见的数据结构。

在这个可选的过程中，其实并没有什么标准答案，我们可以根据需要将不同的数据转换成不同的数据结构：

比如，将数组变成字符串或者一对多关系，将哈希变成当前文档的键值对等等，如何处理这些集合数据其实都要看我们的业务逻辑，在改变这些字段的同时尽量为上层提供一个与原来直接 .tags 或者 .categories 结果相同的 API：

class Post
  ...
  def tag_titles
    tags.map(&:title)
  end

  def split_categories
    categories.split(',')
  end
end

这一步其实也是可选的，上述代码只是为了减少其他地方的修改负担，当然如果你想使用 MySQL5.7 或者 PostgreSQL 数据库对 JSON 的支持也没有什么太大的问题，只是在查询集合字段时有一些不方便。

Mongoid 的『小兄弟』们

在使用 Mongoid 进行开发期间难免会用到一些相关插件，比如 mongoid-enum、mongoid-slug 和 mongoid-history 等，这些插件的实现与 ActiveRecord 中具有相同功能的插件在实现上有很大的不同。

对于有些插件，比如 mongoid-slug 只是在引入插件的模型的文档中插入了 _slugs 字段，我们只需要在进行数据迁移忽略这些添加的字段并将所有的 #slug 方法改成 #id，不需要在预处理的过程中做其它的改变。而枚举的实现在 Mongoid 的插件和 ActiveRecord 中就截然不同了：

mongoid-enum 使用字符串和 _status 来保存枚举类型的字段，而 ActiveRecord 使用整数和 status 表示枚举类型，两者在底层数据结构的存储上有一些不同，我们会在之后的迁移脚本中解决这个问题。

如果在项目中使用了很多 Mongoid 的插件，由于其实现不同，我们也只能根据不同的插件的具体实现来决定如何对其进行迁移，如果使用了一些支持特殊功能的插件可能很难在 ActiveRecord 中找到对应的支持，在迁移时可以考虑暂时将部分不重要的功能移除。

主键与 UUID

我们希望从 MongoDB 迁移到 MySQL 的另一个重要原因就是 MongoDB 每一个文档的主键实在是太过冗长，一个 32 字节的 _id 无法给我们提供特别多的信息，只能增加我们的阅读障碍，再加上项目中并没有部署 MongoDB 集群，所以没能享受到用默认的 UUID 生成机制带来的好处。

我们不仅没有享受到 UUID 带来的有点，它还在迁移 MySQL 的过程中为我们带来了很大的麻烦，一方面是因为 ActiveRecord 的默认主键是整数，不支持 32 字节长度的 UUID，如果我们想要不改变 MongoDB 的 UUID，直接迁移到 MySQL 中使用其实也没有什么问题，只是我们要将默认的整数类型的主键变成字符串类型，同时要使用一个 UUID 生成器来保证所有的主键都是根据时间递增的并且不会冲突。

如果准备使用 UUID 加生成器的方式，其实会省去很多迁移的时间，不过看起来确实不是特别的优雅，如何选择还是要权衡和评估，但是如果我们选择了使用 integer 类型的自增主键时，就需要做很多额外的工作了，首先是为所有的表添加 uuid 字段，同时为所有的外键例如 post_id 创建对应的 post_uuid 字段，通过 uuid 将两者关联起来：

在数据的迁移过程中，我们会将原有的 _id 映射到 uuid 中，post_id 映射到 post_uuid 上，我们通过保持 uuid 和 post_uuid 之间的关系保证模型之间的关系没有丢失，在迁移数据的过程中 id 和 post_id 是完全不存在任何联系的。

当我们按照 _id 的顺序遍历整个文档，将文档中的数据被插入到表中时，MySQL 会为所有的数据行自动生成的递增的主键 id，而 post_id 在这时都为空。

在全部的数据都被插入到 MySQL 之后，我们通过 #find_by_uuid 查询的方式将 uuid 和 post_uuid 中的关系迁移到 id 和 post_id 中，并将与 uuid 相关的字段全部删除，这样我们能够保证模型之间的关系不会消失，并且数据行的相对位置与迁移前完全一致。

代码的迁移

Mongoid 在使用时都是通过 include 将相关方法加载到当前模型中的，而 ActiveRecord 是通过继承 ActiveRecord::Base 的方式使用的，完成了对数据的预处理，我们就可以对现有模型层的代码进行修改了。

首先当然是更改模型的『父类』，把所有的 Mongoid::Document 都改成 ActiveRecord::Base，然后创建类对应的 Migration 迁移文件：

# app/models/post.rb
class Post < ActiveRecord::Base
  validate_presence_of :title, :content
end

# db/migrate/20170908075625_create_posts.rb
class CreatePosts < ActiveRecord::Migration[5.1]
  def change
    create_table :posts do |t|
      t.string :title, null: false
      t.text :content, null: false
      t.string :uuid, null: false

      t.timestamps null: false
    end

    add_index :posts, :uuid, unique: true
  end
end

注意：要为每一张表添加类型为字符串的 uuid 字段，同时为 uuid 建立唯一索引，以加快通过 uuid 建立不同数据模型之间关系的速度。

除了建立数据库的迁移文件并修改基类，我们还需要修改一些 include 的模块和 Mongoid 中独有的查询，比如使用 gte 或者 lte 的日期查询和使用正则进行模式匹配的查询，这些查询在 ActiveRecord 中的使用方式与 Mongoid 中完全不同，我们需要通过手写 SQL 来解决这些问题。

除此之外，我们也需要处理一些复杂的模型关系，比如 Mongoid 中的 inverse_of 在 ActiveRecord 中叫做 foreign_key 等等，这些修改其实都并不复杂，只是如果想要将这部分的代码全部处理掉，就需要对业务逻辑进行详细地测试以保证不会有遗留的问题，这也就对我们项目的测试覆盖率有着比较高的要求了，不过我相信绝大多数的 Rails 工程都有着非常好的测试覆盖率，能够保证这一部分代码和逻辑能够顺利迁移，但是如果项目中完全没有测试或者测试覆盖率很低，就只能人肉进行测试或者自求多福了，或者就别做迁移了，多写点测试再考虑这些重构的事情吧。

数据的迁移

为每一个模型创建对应的迁移文件并建表其实一个不得不做的体力活，虽然有一些工作我们没法省略，但是我们可以考虑使用自动化的方式为所有的模型添加 uuid 字段和索引，同时也为类似 post_id 的字段添加相应的 post_uuid 列：

class AddUuidColumns < ActiveRecord::Migration[5.1]
  def change
    Rails.application.eager_load!
    ActiveRecord::Base.descendants.map do |klass|
      # add `uuid` column and create unique index on `uuid`.
      add_column klass.table_name, :uuid, :string, unique: true
      add_index klass.table_name, unique: true

      # add `xxx_uuid` columns, ex: `post_uuid`, `comment_uuid` and etc.
      uuids = klass.attribute_names
        .select { |attr| attr.include? '_id' }
        .map    { |attr| attr.gsub '_id', '_uuid' }
      next unless uuids.present?
      uuids.each do |uuid|
        add_column klass.table_name, uuid, :string
      end
    end
  end
end

在添加 uuid 列并建立好索引之后，我们就可以开始对数据库进行迁移了，如果我们决定在迁移的过程中改变原有数据的主键，那么我们会将迁移分成两个步骤，数据的迁移和关系的重建，前者仅指将 MongoDB 中的所有数据全部迁移到 MySQL 中对应的表中，并将所有的 _id 转换成 uuid、xx_id 转换成 xx_uuid，而后者就是前面提到的：通过 uuid 和 xx_uuid 的关联重新建立模型之间的关系并在最后删除所有的 uuid 字段。

我们可以使用如下的代码对数据进行迁移，这段代码从 MongoDB 中遍历某个集合 Collection 中的全部数据，然后将文档作为参数传入 block，然后再分别通过 DatabaseTransformer#delete_obsolete_columns 和 DatabaseTransformer#update_rename_columns 方法删除部分已有的列、更新一些数据列最后将所有的 id 列都变成 uuid：

module DatabaseTransformer
  def import(collection_name, *obsolete_columns, **rename_columns)
    collection = Mongoid::Clients.default.collections.select do |c|
      c.namespace == "#{database}.#{collection_name.to_s.pluralize}"
    end.first

    unless collection.present?
      STDOUT.puts "#{collection_name.to_s.yellow}: skipped"
      STDOUT.puts
      return
    end

    constant = collection_name.to_s.singularize.camelcase.constantize
    reset_callbacks constant

    DatabaseTransformer.profiling do
      collection_count = collection.find.count
      collection.find.each_with_index do |document, index|
        document = yield document if block_given?
        delete_obsolete_columns document, obsolete_columns
        update_rename_columns document, rename_columns
        update_id_columns document

        insert_record constant, document
        STDOUT.puts "#{index}/#{collection_count}\n" if (index % 1000).zero?
      end
    end
  end
end

当完成了对文档的各种操作之后，该方法会直接调用 DatabaseTransformer#insert_record 将数据插入 MySQL 对应的表中；我们可以直接使用如下的代码将某个 Collection 中的全部文档迁移到 MySQL 中：

transformer = DatabaseTransformer.new 'draven_production'
transformer.import :post, :_slugs, name: :title, _status: :status

上述代码会在迁移时将集合每一个文档的 _slugs 字段全部忽略，同时将 name 重命名成 title、_status 重命名成 status，虽然作为枚举类型的字段 mongoid-enum 和 ActiveRecord 的枚举类型完全不同，但是在这里可以直接插入也没有什么问题，ActiveRecord 的模型在创建时会自己处理字符串和整数之间的转换：

def insert_record(constant, params)
  model = constant.new params
  model.save! validate: false
rescue Exception => exception
  STDERR.puts "Import Error: #{exception}"
  raise exception
end

为了加快数据的插入速度，同时避免所有由于插入操作带来的副作用，我们会在数据迁移期间重置所有的回调：

def reset_callbacks(constant)
  %i(create save update).each do |callback|
    constant.reset_callbacks callback
  end
end

这段代码的作用仅在这个脚本运行的过程中才会生效，不会对工程中的其他地方造成任何的影响；同时，该脚本会在每 1000 个模型插入成功后向标准输出打印当前进度，帮助我们快速发现问题和预估迁移的时间。

你可以在 database_transformer.rb 找到完整的数据迁移代码。

将所有的数据全部插入到 MySQL 的表之后，模型之间还没有任何显式的关系，我们还需要将通过 uuid 连接的模型转换成使用 id 的方式，对象之间的关系才能通过点语法直接访问，关系的建立其实非常简单，我们获得当前类所有结尾为 _uuid 的属性，然后遍历所有的数据行，根据 uuid 的值和 post_uuid 属性中的 "post" 部分获取到表名，最终得到对应的关联模型，在这里我们也处理了类似多态的特殊情况：

module RelationBuilder
  def build_relations(class_name, polymorphic_associations = [], rename_associations = {})
    uuids = class_name.attribute_names.select { |name| name.end_with? '_uuid' }

    unless uuids.present?
      STDOUT.puts "#{class_name.to_s.yellow}: skipped"
      STDOUT.puts
      return
    end

    reset_callbacks class_name

    RelationBuilder.profiling do
      models_count = class_name.count
      class_name.unscoped.all.each_with_index do |model, index|
        update_params = uuids.map do |uuid|
          original_association_name = uuid[0...-5]

          association_model = association_model(
            original_association_name,
            model[uuid],
            polymorphic_associations,
            rename_associations
          )

          [original_association_name.to_s, association_model]
        end.compact

        begin
          Hash[update_params].each do |key, value|
            model.send "#{key}=", value
          end
          model.save! validate: false
        rescue Exception => e
          STDERR.puts e
          raise e
        end

        STDOUT.puts "#{index}/#{models_count}\n" if (counter % 1000).zero?
      end
    end
  end
end

在查找到对应的数据行之后就非常简单了，我们调用对应的 post= 等方法更新外键最后直接将外键的值保存到数据库中，与数据的迁移过程一样，我们在这段代码的执行过程中也会打印出当前的进度。

在初始化 RelationBuilder 时，如果我们传入了 constants，那么在调用 RelationBuilder#build! 时就会重建其中的全部关系，但是如果没有传入就会默认加载 ActiveRecord 中所有的子类，并去掉其中包含 :: 的模型，也就是 ActiveRecord 中使用 has_and_belongs_to_many 创建的中间类，我们会在下一节中介绍如何单独处理多对多关系：

def initialize(constants = [])
  if constants.present?
    @constants = constants
  else
    Rails.application.eager_load!
    @constants = ActiveRecord::Base.descendants
        .reject { |constant| constant.to_s.include?('::') }
  end
end

跟关系重建相关的代码可以在 relation_builder.rb 找到完整的用于关系迁移的代码。

builder = RelationBuilder.new([Post, Comment])
builder.build!

通过这数据迁移和关系重建两个步骤就已经可以解决绝大部分的数据迁移问题了，但是由于 MongoDB 和 ActiveRecord 中对于多对多关系的处理比较特殊，所以我们需要单独进行解决，如果所有的迁移问题到这里都已经解决了，那么我们就可以使用下面的迁移文件将数据库中与 uuid 有关的全部列都删除了：

class RemoveAllUuidColumns < ActiveRecord::Migration[5.1]
  def change
    Rails.application.eager_load!
    ActiveRecord::Base.descendants.map do |klass|
      attrs = klass.attribute_names.select { |n| n.include? 'uuid' }
      next unless attrs.present?
      remove_columns klass.table_name, *attrs
    end
  end
end

到这里位置整个迁移的过程就基本完成了，接下来就是跟整个迁移过程中有关的其他事项，例如：对多对关系、测试的重要性等话题。

多对多关系的处理

多对多关系在数据的迁移过程中其实稍微有一些复杂，在 Mongoid 中使用 has_and_belongs_to_many 会在相关的文档下添加一个 tag_ids 或者 post_ids 数组：

# The post document.
{
  "_id" : ObjectId("4d3ed089fb60ab534684b7e9"),
  "tag_ids" : [
    ObjectId("4d3ed089fb60ab534684b7f2"), 
    ObjectId("4d3ed089fb60ab53468831f1")
  ],
  "title": "xxx",
  "content": "xxx"
}

而 ActiveRecord 中会建立一张单独的表，表的名称是两张表名按照字母表顺序的拼接，如果是 Post 和 Tag，对应的多对多表就是 posts_tags，除了创建多对多表，has_and_belongs_to_many 还会创建两个 ActiveRecord::Base 的子类 Tag::HABTM_Posts 和 Post::HABTM_Tags，我们可以使用下面的代码简单实验一下：

require 'active_record'

class Tag < ActiveRecord::Base; end
class Post < ActiveRecord::Base
  has_and_belongs_to_many :tags
end
class Tag < ActiveRecord::Base
  has_and_belongs_to_many :posts
end
puts ActiveRecord::Base.descendants
# => [Tag, Post, Post::HABTM_Tags, Tag::HABTM_Posts]

上述代码打印出了两个 has_and_belongs_to_many 生成的类 Tag::HABTM_Posts 和 Post::HABTM_Tags，它们有着完全相同的表 posts_tags，处理多对多关系时，我们只需要在使用 DatabaseTransformer 导入表中的所有的数据之后，再通过遍历 posts_tags 表中的数据更新多对多的关系表就可以了：

class PostsTag < ActiveRecord::Base; end

# migrate data from mongodb to mysql.
transformer = DatabaseTransformer.new 'draven_production'
transformer.import :posts_tags

# establish association between posts and tags.
PostsTag.unscoped.all.each do |model|
  post = Post.find_by_uuid model.post_uuid
  tag = Tag.find_by_uuid model.tag_uuid
  next unless post.present? && tag.present?
  model.update_columns post_id: post.id, tag_id: tag.id
end

所有使用 has_and_belongs_to_many 的多对多关系都需要通过上述代码进行迁移，这一步需要在删除数据库中的所有 uuid 字段之前完成。

测试的重要性

在真正对线上的服务进行停机迁移之前，我们其实需要对数据库已有的数据进行部分和全量测试，在部分测试阶段，我们可以在本地准备一个数据量为生产环境数据量 1/10 或者 1/100 的 MongoDB 数据库，通过在本地模拟 MongoDB 和 MySQL 的环境进行预迁移，确保我们能够尽快地发现迁移脚本中的错误。

准备测试数据库的办法是通过关系删除一些主要模型的数据行，在删除时可以通过 MongoDB 中的 dependent: :destroy 删除相关的模型，这样可以尽可能的保证数据的一致性和完整性，但是在对线上数据库进行迁移之前，我们依然需要对 MongoDB 中的全部数据进行全量的迁移测试，这样可以发现一些更加隐蔽的问题，保证真正上线时可以出现更少的状况。

数据库的迁移其实也属于重构，在进行 MongoDB 的数据库迁移之前一定要保证项目有着完善的测试体系和测试用例，这样才能让我们在项目重构之后，确定不会出现我们难以预料的问题，整个项目才是可控的，如果工程中没有足够的测试甚至没有测试，那么就不要再说重构这件事情了 -- 单元测试是重构的基础。

总结

如何从 MongoDB 迁移到 MySQL 其实是一个工程问题，我们需要在整个过程中不断寻找可能出错的问题，将一个比较复杂的任务进行拆分，在真正做迁移之前尽可能地减少迁移对服务可用性以及稳定性带来的影响。

除此之外，MongoDB 和 MySQL 之间的选择也不一定是非此即彼，我们将项目中的大部分数据都迁移到了 MySQL 中，但是将一部分用于计算和分析的数据留在了 MongoDB，这样就可以保证 MongoDB 宕机之后仍然不会影响项目的主要任务，同时，MySQL 的备份和恢复速度也会因为数据库变小而非常迅速。

最后一点，测试真的很重要，如果没有测试，没有人能够做到在修改大量的业务代码的过程中不丢失任何的业务逻辑，甚至如果没有测试，很多业务逻辑可能在开发的那一天就已经丢失了。

原文链接：如何从 MongoDB 迁移到 MySQL · 面向信仰编程

Reference

How do I migrate data from a MongoDB to MySQL database? · Quora

====

一年多了，一直都在社区潜水，这次出来发个帖子 [捂脸]

用 Rails 写 API 服务，性能感觉不足，怎么办？

sefier — Tue, 25 Jul 2017 13:31:53 +0800

我有一个 Rails 5 的 Web 项目，同时有三个 API 接口，我就直接写到 rails controller 里面，返回 json 结果了。这个方案最简单，但是随着 api 调用达到 2 万的 rps 之后，性能急剧下降。

我没做仔细评估，考虑到数据库压力，所以首先是改写了接口的实现，全部数据都采取读写 redis 的方式，然后异步更新到数据库中。这个方案实现后，性能确实很大提升，但是速度依然难以接受。我查看 new relic，发现非数据库非 redis 的底层占用时间巨大，是服务器性能不足吗？服务器集群已经加到 150 台了，有点不理智了。

这种情况该怎么办？有没有剥离 api 的好办法？因为毕竟跟 rails web 的基础项目有一定的关联，是不是要换个框架专门写 api，还是换一种语言来做？

谢谢。

Routes 文件模块太多，想把定义的 admin、account、site 等等模块分别在不同文件里写，有方法吗？

lengcb — Mon, 05 Jun 2017 10:30:29 +0800

我的 routes.rb 文件里面模块太多，我想把定义的 admin、account、site 等等模块分别在不同文件里写，然后在 routes.rb 文件里引用，有方法吗？

多个 Rails 项目中都会用到的代码，怎样抽象更加方便管理更新？

crayygy — Thu, 01 Jun 2017 16:02:28 +0800

目前遇到的一个问题是，公司内部若干项目，均需要采用一套内网的登录验证，因此几个项目中这一块的代码是完全相同的。但是又是非常特定的环境，有时候需要针对内网验证变化来更新代码，因此会变得很繁琐。

刚好最近几个项目要迁移 code base，没有很多的需求要做，有空来思考一下重构这一部分的代码，方便以后的更新。

想请教一下大家有没有什么比较好的建议。

我也算是半吊子出家的 Ruby 程序员，有些东西还不算很清楚，如果没有描述的很清楚的话，还请见谅。

最近在选型基础平台，求建议

fengfans — Fri, 21 Apr 2017 20:42:35 +0800

数字化校园，有必要用到 esb 吗？微服务架构中需要吗？

这种代码有什么好的重构方法吗？

xiaoping_rubyist — Thu, 12 Jan 2017 14:48:22 +0800

这种代码有什么好的重构吗？

def _assign_network_from_db
  begin
    @nodes.each do |node_name, node|
      next if node["topology_resource_id"].nil?
      topology_resource            = TopologyResource.find(node["topology_resource_id"])
      @interfaces[node_name].each do |interface_name,interface|
        iface =   topology_resource.topology_resource_interfaces.find_by_name interface_name
        if !iface.nil?
          if !iface.topology_vlan_id.nil?

            # Find the vlan details from DB and set them
            topology_vlan     = TopologyVlan.find(iface.topology_vlan_id)
            vlan              = topology_vlan.vlan
            physnet           = topology_vlan.physnet
            external_network  = topology_vlan.external_network
            if interface["ip"].nil?
              interface["ip"]               = iface.ip
            end
            if interface["network"].nil?
              interface["network"]          = iface.network
            end
            if interface["share_network"].nil?
              interface["vlan"]             = vlan
            end
            interface["physnet"]          = physnet
            interface["external_network"] = external_network
            interface["switch_id"]        = iface.switch_id
            interface["switch_port"]      = iface.switch_port
            topology_vlan.status = 'INUSE'
            topology_vlan.save!

          elsif !iface.nil? && !iface.ip.nil?
            if interface["ip"].nil?
              interface["ip"] = iface.ip
            end
            if interface["network"].nil?
              interface["network"] = iface.network
            end
            interface["skip_network"] = true
          end
        elsif !interface_name.match(/X\d:\d+/i).nil?
          # deal with the subinterface(like: X1:1) of UTM by Rex
          iface_parent_name = interface_name.split(":")[0]
          iface_parent = topology_resource.topology_resource_interfaces.find_by_name iface_parent_name

          vlan_result       =  _get_private_vlan
          vlan              = vlan_result["vlan"]
          physnet           = vlan_result["physnet"]
          external_network  = vlan_result["external_network"]

          interface["physnet"]          = physnet
          interface["external_network"] = external_network
          interface["switch_id"]        = iface_parent.switch_id
          interface["switch_port"]      = iface_parent.switch_port   

          if interface["share_network"].nil? then
            interface["vlan"]             = vlan
          end
        end

        if !interface["remote_node"].nil? && interface["routed_connection"].nil? then
          remote_node_name      = interface["remote_node"]
          remote_interface_name = interface["remote_interface"]
          interface["network"]  = nil if interface["network"].to_s.match(/\d/).nil?
          @interfaces[remote_node_name][remote_interface_name]["network"]          = interface["network"] 
          @interfaces[remote_node_name][remote_interface_name]["vlan"]             = vlan
          @interfaces[remote_node_name][remote_interface_name]["physnet"]          = physnet
          @interfaces[remote_node_name][remote_interface_name]["external_network"] = external_network
        end
      end
    end
  rescue => e
    self.status    = "error"
    self.message   = "Error occured while assigning network details from db. #{e}"
    self.backtrace = e.backtrace
    return
  end
end

常见重构手法 (下)

qinfanpeng — Thu, 29 Dec 2016 19:11:07 +0800

原文地址：http://qinfanpeng.github.io/jekyll/update/2016/12/18/common_refactor_skills_part_two.html

Common Reactor Skills Part Two

[slide]

Agenda

Replace Magic number with Constant {:&.fadeIn}
Decompose Conditional
Replace Nested Conditional with Guard Clauses
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Remove Control Flag
Sparate Query from Modifer
Introduce Named Parameter

[slide]

Agenda

Replace Magic number with Constant
Decompose Conditional
Replace Nested Conditional with Guard Clauses
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Remove Control Flag
Sparate Query from Modifer
Introduce Named Parameter

[slide]

const calculatePrice = (order) => {
    return basePrice(order) - quantityDiscount(order) + shipping(order)
}

const quantityDiscount = ({ itemPrice }) => {
    return Math.max(0, quantity - 500) * itemPrice * 0.05
}

const shipping = function (order) {
    return Math.min(100, basePrice(order) * 0.1)
}

改善空间？

魔法数不可读，妨碍理解 {:&.fadeIn}
魔法数容易重复，从而散落于代码各处，致使散弹式修改
不具备可搜索性

[slide]

Replace Magic number with Constant(用常量替换魔法数)

const QUANTITY_DISCOUNT_THRESHOLD = 500
const QUANTITY_DISCOUNT_RATE = 500
const SHIPPING_RATE = 0.1
const MIN_SHIPPING = 100

const quantityDiscount = ({ itemPrice }) => {
    return Math.max(0, quantity - QUANTITY_DISCOUNT_THRESHOLD) * itemPrice * QUANTITY_DISCOUNT_RATE
}

var shipping = function (order) {
    return Math.min(MIN_SHIPPING, basePrice(order) * SHIPPING_RATE)
}

[slide]

思考 - 放置常量的位置？

变化频率 {:&.fadeIn}
使用范围

[note] 变化越频繁、使用范围越广，更应放到全局性的地方，甚至是配置文件；使用范围、变化越少，则可就近放置（比如当前文件顶部？） [/note]

[slide]

字符串字面量与魔法数的异同？

const shipping = function (order) {
    return Math.min(100, basePrice(order) * 0.1)
}

determineLegendAlignment(model, ['top', 'topCenter'])
determineLegendAlignment(model, ['left', 'leftMiddle'])
determineLegendAlignment(model, ['right', 'rightMiddle', 'rightBottom'])
determineLegendAlignment(model, ['bottom', 'bottomCenter'])

和魔法数的异同？

“魔法数不可读，妨碍理解”，字符串字面量无此问题 {:&.fadeIn}
“魔法数容易重复，从而散落于代码各处，致使散弹式修改”，有此问题，但频率不高
字符串字面量容易出现拼写错误
要不要抽常量？个人觉得尽量抽

[slide]

const calculateCharge = (date, quantity) => {
  if (SUMMER_START <= date && date <= SUMMER_END) {
    return quantity * SUMMER_RATE
  } else {
    return quantity * WINTER_RATE + WINTER_SERVICE_CHARGE 
  }
}

改善空间？

未能突出领域概念 {:&.fadeIn}
未能突出各个分支

[slide]

Decompose Conditional(分解条件表达式)

const calculateCharge = (date, quantity) => {
  if (SUMMER_START <= date && date <= SUMMER_END) {
    return quantity * SUMMER_RATE
  } else {
    return quantity * WINTER_RATE + WINTER_SERVICE_CHARGE 
  }
}

const calculateCharge = (date, quantity) => {
  return isInSummer(date) ? summerCharge(date) : winterCharge(date)
}

const isInSummer = (date) => SUMMER_START <= date && date <= SUMMER_END

const summerCharge = (quantity) => quantity * SUMMER_RATE

const winterCharge = (quantity) => quantity * WINTER_RATE + WINTER_SERVICE_CHARGE

[slide]

[magic data-transition="cover-circle"]

最容易从以下代码结构联想到什么？

const calculatePayAmount = () => {
  let result = 0.0

  if (isDead()) {
    result = deadAmount()
  } else {
    if (isSeparated()) {
      result = separatedAmount()
    } else {
      if (isRetired()) {
        result = retiredAmount()
      } else {
        result = normalPayAmount()
      }
    }
  }

  return result
}

====

改善空间？

条件嵌套，致使阅读负担陡增，不容易找出主要逻辑
摆脱单一出口原则的束缚
乱用 if-else 结构

[/magic]

[slide]

if-else 结构意味着什么？

两个分支都是正常情况 {:&.zoomIn}
两个分支重要程度相当，该受到相同的重视程度
两个分支发生的概率相当
两个分支确实属于非此即彼的关系

[slide]

Guard Clauses（卫语句）

const calculatePayAmount = () => {
  if (isDead()) return deadAmount()
  if (isSeparated()) return separatedAmount()

  // ...
  // ...
  // ...

卫语句意味着什么？

这种情况很罕见，如果它真地发生了，稍作处理，退出即可 {:&.zoomIn}

[slide]

何时使才用 if-else？

两个分支都是正常情况 {:&.zoomIn}
两个分支重要程度相当，该受到相同的重视程度
两个分支发生的概率相当
两个分支确实属于非此即彼的关系
两个分支代码量相当

[slide]

[magic data-transition="cover-circle"]

影响选用 if-else/卫语句的因数

-- 主要观察点：两个分支是否都是正常情况

const computeDisabilityAmount = () => {
  if (isNotEligibleForDisability()) {
    return 0.0
  } else {
    // compute disability amount
    // ...
    // ...
  }
}

const isNotEligibleForDisability = () => {
  return seniority < 0 || monthsDisabled > 12 || isPartTime()
}

====

const computeDisabilityAmount = () => {
  if (isNotEligibleForDisability()) return 0.0

  // compute disability amount
  // compute disability amount
  // ...
  // ...
}

const isNotEligibleForDisability = () => {
  return seniority < 0 || monthsDisabled > 12 || isPartTime()
}

[/magic]

[slide]

[magic data-transition="cover-circle"]

影响选用 if-else/卫语句的因数

-- 主要观察点：两个分支代码量是否相当

handleCellWithTooltip(fieldValue, field) {
    if (this.props.needTooltipFieldNames.includes(field)) {
      const tooltipId = uniqueId('fieldValue_')
      return (
        <span key={tooltipId}>
          <div data-tip data-for={tooltipId}>{fieldValue}</div>
          <Tooltip id={tooltipId} place='right'>
            <div>{fieldValue}</div>
          </Tooltip>
        </span>
      )
    } else {
      return <span key={uniqueId('cell_')}>{fieldValue}</span>
    }
  }

====

handleCellWithTooltip(fieldValue, field) {
    if (!this.props.needTooltipFieldNames.includes(field)) return <span key={uniqueId('cell_')}>{fieldValue}</span>

   const tooltipId = uniqueId('fieldValue_')
   return (
     <span key={tooltipId}>
       <div data-tip data-for={tooltipId}>{fieldValue}</div>
       <Tooltip id={tooltipId} place='right'>
         <div>{fieldValue}</div>
       </Tooltip>
     </span>
   )
}

[/magic]

[slide]

Replace Nested Conditional with Guard Clauses (用卫语句替换嵌套条件表达式)


const calculatePayAmount = () => {
  let result = 0.0

  if (isDead()) {
    result = deadAmount()
  } else {
    if (isSeparated()) {
      result = separatedAmount()
    } else {
      if (isRetired()) {
        result = retiredAmount()
      } else {
        result = normalPayAmount()
      }
    }
  }

  return result
}



const calculatePayAmount = () => {
  if (isDead()) return deadAmount()
  if (isSeparated()) return separatedAmount()
  if (isRetired()) return retiredAmount()
  
  return normalPayAmount()
}

[slide]

[magic data-transition="cover-circle"]

消除条件嵌套

const getAdjustedCapital = () => {
  const result = 0

  if (capital > 0) {
    if (intRate > 0 && duration > 0) {
      result = (_income / _duration) * ADJ_FACTOR
    }
  }

  return result
}

====

条件取反 -- 识别异常情况

const getAdjustedCapital = () => {
  if (capital <= 0) return 0
  if (!(intRate > 0 && duration > 0)) return 0

  return (_income / _duration) * ADJ_FACTOR
}

====

简化取反后的条件

const getAdjustedCapital = () => {
  if (capital <= 0) return 0
  if (intRate <= 0 || duration <= 0)) return 0

  return (_income / _duration) * ADJ_FACTOR
}

[/magic]

[slide]

使用 if-else 的注意事项

尽量避免条件表达式嵌套 {:&.zoomIn}
个人建议别优先使用 if-else

[slide]

const computeDisabilityAmount = () => {
  if (seniority < 0) return 0
  if (monthsDisabled > 12) return 0
  if (isPartTime()) return 0

  // compute disability amount
}

改善空间？

喧宾夺主，函数很大一部分空间被验证逻辑霸占 {:&.fadeIn}
可以合并的条件检测

[slide]

Consolidate Conditional Expression(合并条件表达式)

const computeDisabilityAmount = () => {
  if (seniority < 0) return 0
  if (monthsDisabled > 12) return 0
  if (isPartTime()) return 0

  // compute disability amount
}

{:&.fadeIn}

const computeDisabilityAmount = () => {
  if (seniority < 0 || monthsDisabled > 12 || isPartTime()) return 0
  // compute disability amount
}

const computeDisabilityAmount = () => {
  isNotEligibleForDisability() return 0
  // compute disability amount
}

const isNotEligibleForDisability = () => {
  return seniority < 0 || monthsDisabled > 12 || isPartTime()
}

[slide]

if (isSpecialDeal()) {
  totalPrice = price * SPECIAL_DEAL_DISCOUNT_RATE
  send()
} else {
  totalPrice = price * NORMAL_DISCOUNT_RATE
  send()
}

改善空间？

并没严格把变和不变区分开 {:&.fadeIn}

[slide]

Consolidate Duplicate Conditional Fragments (合并重复条件代码片段)

if (isSpecialDeal()) {
  totalPrice = price * SPECIAL_DEAL_DISCOUNT_RATE
  send()
} else {
  totalPrice = price * NORMAL_DISCOUNT_RATE
  send()
}

if (isSpecialDeal()) {
  totalPrice = price * SPECIAL_DEAL_DISCOUNT_RATE
} else {
  totalPrice = price * NORMAL_DISCOUNT_RATE
}
send()

[slide]

Demo of Consolidate Duplicate Conditional Fragments

handleMenuOnChange(selectedItem) {
  if (this.props.length > 1) {
    this.setState({
      selectedMeasure:{
        fieldId: selectedItem.value
      }
    })
  }
  else {
    this.setState({
      selectedMeasure: selectedItem.measure
    })
  }
}

{:&.fadeIn}

handleMenuOnChange(selectedItem) {
  const selectedMeasure = this.props.measures.length > 1 ? {fieldId: selectedItem.value} : selectedItem.measure 
  this.setState({ selectedMeasure })
}

[slide]

const checkSecurity = (people) => {
  const miscreant = findMiscreant(people)
  // doSomethingElse(miscreant)
}

const findMiscreant = (people) => {
  let found = false
  people.forEach(person => {
    if (!found) {
      if (person === 'Bob') {
        sendAlert()
        found = true
      }
      if (person === 'Jack') {
        sendAlert()
        found = true
      }
    }
  })
}

改善空间？

丑陋的控制位（found） {:&.fadeIn}
查询函数中暗含副作用，且无法从函数名中看出
臃肿的 for 循环

[slide]

[magic data-transition="cover-circle"]

Remove Control Flag (移除控制位)

-- 移除前

const findMiscreant = (people) => {
  let found = false
  people.forEach(person => {
    if (!found) {
      if (person === 'Bob') {
        sendAlert()
        found = true
      }
      if (person === 'Jack') {
        sendAlert()
        found = true
      }
    }
  })
}

====

Remove Control Flag (移除控制位)

-- 移除后

const findMiscreant = (people) => {
  people.forEach(person => {
      if (person === 'Bob') {
        sendAlert()
        break;
      }
      if (person === 'Jack') {
        sendAlert()
        break;
      }
    }
  })
}

[/magic]

[slide]

[magic data-transition="cover-circle"]

Sparate Query from Modifer (将查询函数和修改函数分开)

-- 分离前

const findMiscreant = (people) => {
  people.forEach(person => {
      if (person === 'Bob') {
        sendAlert()
        break;
      }
      if (person === 'Jack') {
        sendAlert()
        break;
      }
    }
  })
}

====

Sparate Query from Modifer (将查询函数和修改函数分开)

-- 分离后

const checkSecurity = (people) => {
  const miscreant = findMiscreant(people)
  if (!isUndefined(miscreant)) sendAlert(miscreant)
  // doSomethingElse(miscreant)
}

const findMiscreant = (people) => {
  const miscreants = ['Bob', 'Jack']
  return find(people, person => miscreants.includes(person))
}

====

Sparate Query from Modifer (将查询函数和修改函数分开)

-- 万不得已

const findMiscreantAndSendAlert = (people) => {
  people.forEach(person => {
    if (!found) {
      if (person === 'Bob') {
        sendAlert(person)
        return person
      }
      if (person === 'Jack') {
        sendAlert(person)
        return person
      }
    }
  })
}

[/magic]

[slide]

const SearchCriteria = buildSearchCriteria(5, "0201485672")

{:&.fadeIn}

const SearchCriteria = buildSearchCriteria(5, "0201485672", false)

buildSearchCriteria(5, "0201485672", false, 'JavaScript : The Good Parts')

const buildSearchCriteria = (authorId, ISBN, includeSoldOut, title) => {
  // ...
}

改善空间？

实参为数字、布尔值时不可读 {:&.fadeIn}
参数较多时，逻辑混乱，不易理解，且容易弄错参数顺序

[slide]

[magic data-transition="cover-circle"]

Introduce Named Parameter (引入具名参数)

const buildSearchCriteria = ({ authorId, ISBN, includeSoldOut, title }) => {
  // ...
}

const SearchCriteria = buildSearchCriteria({
  authorId: 5, 
  ISBN: "0201485672", 
  includeSoldOut: false, 
  title: 'JavaScript : The Good Parts'
})

====

至少提取解释变量

const **authorId** = 5
const ISBN = '0201485672'
const includeSoldOut = false
const title = 'JavaScript The Good Parts'

const SearchCriteria = buildSearchCriteria(authorId, ISBN, includeSoldOut, title)

[/magic]

[slide]

参考资料

《重构》
《编写可读的艺术》
《代码整洁之道》

[slide]

Thank You & QA

常见重构手法 (上)

qinfanpeng — Wed, 21 Dec 2016 09:14:48 +0800

经多处比较，发现还算 ThoughtWorks 和金数据的小伙伴比较喜欢追求优雅的代码。http://qinfanpeng.github.io/jekyll/update/2016/12/15/common_refactor_skills_part_one.html

[slide]

Agenda

Introduce Explaining Variable
Replace Temp with Query
Inline Temp
Extract Method
Inline Method
Substitue Algorithm
Split Temoary Variable
Remove Assignments to Parameters

[slide]

Agenda

Introduce Explaining Variable
Replace Temp with Query
Inline Temp
Extract Method
Inline Method
Substitue Algorithm
Split Temoary Variable
Remove Assignments to Parameters

[slide]

const calculatePrice = ({ itemPrice, quantity }) => {
  // price is base price - quantity discount + shipping
  return itemPrice * quantity -
      Math.max(0, quantity - 500) * itemPrice * 0.05 +
      Math.min(100, itemPrice * quantity * 0.1)
}

重构信号？

注释 {:&.fadeIn}
表达式逻辑杂糅于细节中，复杂难懂
可读性不高
重复

[slide]

Introduce Explaining Variable(引入解释变量)

const calculatePrice = ({ itemPrice, quantity }) => {
  // price is base price - quantity discount + shipping
  return itemPrice * quantity -
      Math.max(0, quantity - 500) * itemPrice * 0.05 +
      Math.min(100, itemPrice * quantity * 0.1)
}

const calculatePrice = ({ itemPrice, quantity }) => {
    const basePrice = itemPrice * quantity
    const quantityDiscount = Math.max(0, quantity - 500) * itemPrice * 0.05
    const shipping = Math.min(100, basePrice * 0.1)

    return basePrice - quantityDiscount + shipping
}

[note] Demo 好处？

把主逻辑从底层细节中剥离了，更可读
代码自身就充当了注释的作用，
消除了重复 [/note]

[slide]

const calculatePrice = ({ itemPrice, quantity }) => {
    const basePrice = itemPrice * quantity
    const quantityDiscount = Math.max(0, quantity - 500) * itemPrice * 0.05
    const shipping = Math.min(100, basePrice * 0.1)

    return basePrice - quantityDiscount + shipping
}

下一步？

是否真的需要暴露底层的细节 {:&.fadeIn}
是否考虑重用
是否会滋生更长的函数
变量是否值回票价

[slide]

Replace Temp with Query(用查询取代临时变量)

const calculatePrice = ({ itemPrice, quantity }) => {
    const basePrice = itemPrice * quantity
    const quantityDiscount = Math.max(0, quantity - 500) * itemPrice * 0.05
    const shipping = Math.min(100, basePrice * 0.1)

    return basePrice - quantityDiscount + shipping
}

const calculatePrice = (order) => {
    return basePrice(order) - quantityDiscount(order) + shipping(order)
}

const basePrice = ({ itemPrice, quantity }) => {
    return itemPrice * quantity
}

const quantityDiscount = ({ itemPrice, quantity }) => {
    return Math.max(0, quantity - 500) * itemPrice * 0.05
}

var shipping = function (order) {
    return Math.min(100, basePrice(order) * 0.1)
}

[note] 好处？

代码即注释，一目了然
更可重用
抽象层级更协调 [/note]

[slide]

Performance concern of More Small Functions

一般都不会有明显的性能差别 {:&.fadeIn}
即使有细小的区别，代码可读性价值更高
若真有大问题，回退并不麻烦
总之，性能顾虑不能成为我们不抽方法的理由

[slide]

const isBigDeal = (order) => {
  const basePrice = order.basePrice
  return basePrice > 1000
}

变量是否值回票价？

此处变量并没有带来更清晰的语义，反而显得冗余了 {:&.fadeIn}

[slide]

Inline Temp Variable

const isBigDeal = (order) => {
  const basePrice = order.basePrice
  return basePrice > 1000
}

const isBigDeal = (order) => {
  return order.basePrice > 1000
}

[slide]

let temp = 2 * height * width
console.log('perimeter: ', temp)

temp = height * width
console.log('area: ', temp)

重构信号？

temp 不表意，不可读 {:&.fadeIn}
对同一个变量多次赋值（并且内容并无关联），职责不单一

[slide]

Split Temoary Variable(分解临时变量)

let temp = 2 * height * width
console.log('perimeter: ', temp)

temp = height * width
console.log('area: ', temp)

const perimeter = 2 * height * width
console.log('perimeter: ', perimeter)

const area = height * width
console.log('area: ', area)

[slide]

const users = [
  { user: 'barney', age: 36, active: true },
  { user: 'fred',   age: 40, active: false }
]

const activeUsers = []
users.each(user => {
  if (user.active) {
    activeUsers.push(user)
  }
})

遇到循环的时候，多斟酌一下

少告诉计算机怎么做，而应告诉它做什么 {:&.fadeIn}
不利于Parallelize
尽量熟悉集合的 API，如filter、map、reduce、find等

[slide]

Substitue Algorithm(替换算法)

const users = [
  { user: 'barney', age: 36, active: true },
  { user: 'fred',   age: 40, active: false }
]

const activeUsers = []
users.each(user => {
  if (user.active) {
    activeUsers.push(user)
  }
})

{:&.fadeIn}

const activeUsers = filter(users, user => user.active)

const activeUsers = filter(users, 'active')

[slide]

More Examples of Substitue Algorithm

const users = [
  { user: 'barney', age: 36, active: true },
  { user: 'fred',   age: 40, active: false }
]

[magic data-transition="cover-circle"]

let activeUser = null

users.each(user => {
  if (user.active) {
    activeUser = user
    break
 }
})

====

let totalAge = 0
users.each(user => {
  if (user.active) {
    totalAge += user.age
  }
})

[/magic]

[slide]

const discount = (inputVal, quantity) => {
  if (inputVal > 50) inputVal -= 2 
  // ...
  return inputVal  
}

重构信号？

对参数赋值，降低代码清晰度 {:&.fadeIn}
对参数赋值，参数为引用时，极易引入副作用
javascript const aMethod = (aObj) => { aObj.modifyInSomeWay() // That's ok aObj = anotherObj // Bad }

[slide]

Remove Assignments to Parameters(移除对参数的赋值)

const discount = (inputVal, quantity) => {
  if (inputVal > 50) inputVal -= 2 
  // ...
  return inputVal  
}

const discount = (basePrice, quantity) => {
  const finalPrice = basePrice
  if (basePrice > 50) finalPrice -= 2 
  // ...
  return finalPrice  
}

[slide]

Extract Method(提取方法)

const printOwing = (orders) => {
  let outstanding = 0.0
  // print banner
  console.log('*********************************')
  console.log('********* Customer Owes *********')
  console.log('*********************************')
  for (let i = 0; i < orders.length; i++) {
    outstanding += orders[i].amount
  }
  // print details
  console.log('name: ', name)
  console.log('amount: ', outstanding)
}

重构信号？

职责不单一 {:&.fadeIn}
注释
抽象层次不协调，以致于主逻辑淹没其中

[slide]

Extract Method(提取方法)

const printOwing = (orders) => {
  printBanner()

  // print details
  console.log('name: ', name)
  console.log('amount: ', outstanding)
}

const printOwing = (orders) => {
  printBanner()
  const outstanding = calculateOutstanding(orders)
  printDetails(outstanding)
}

const printBanner = () => {
  console.log('*********************************')
  console.log('********* Customer Owes *********')
  console.log('*********************************')
}

var calculateOutstanding = function (orders) {
  return sumBy(orders, 'amount')
}

const printDetails = function (outstanding) {
  console.log('name: ', name)
  console.log('amount: ', outstanding)
}

[slide]

Inline Method(内联方法)

const getRating = () => {
    return moreThanFiveNegativeFeedbacks() ? 1 : 2
}

const moreThanFiveNegativeFeedbacks = () => {
    return this.negativeFeedbacks.length > 5
}

{:&.fadeIn}

const getRating = () => {
    return this.negativeFeedbacks.length > 5 ? 1 : 2
}

[slide]

Summary

[slide]

参考资料

《重构》
《编写可读的艺术》
《代码整洁之道》

[slide]

Thank You & QA

[译] 重构 Rails MVC 组件的 7 个设计模式

freefishz — Wed, 30 Nov 2016 10:47:40 +0800

原文请阅读 7 Design Patterns to Refactor MVC Components in Rails

Service Objects (and Interactor Objects)
Value Objects
Form Objects
Query Objects
View Objects (Serializer/Presenter)
Policy Objects
Decorators

1. Service Objects (and Interactor Objects)

当 Controller 中的 action 有以下症状时适用：

过于复杂（如，计算员工的工资）
调用外部 api 服务
明显不属于任何 model（如，删除过期数据）
使用多个 model（如，从一个文件中导入数据到多个 model）

示例

以下示例中，主要工作由外部 Stripe 服务完成。该服务基于邮件地址和来源创建 Stripe 客户，并将所有服务费用绑定到该客户的账号上。

问题分析

Controller 中包含调用外部服务的代码
Controller 负责构建调用外部服务所需的数据
Controller 难于维护和扩展

class ChargesController < ApplicationController
   def create
     amount = params[:amount].to_i * 100
     customer = .create(
       email: params[:email],
       source: params[:source]
     )
     charge = Stripe::Charge.create(
       customer: customer.id,
       amount: amount,
       description: params[:description],
       currency: params[:currency] || 'USD'
     )
     redirect_to charges_path
   rescue Stripe::CardError => exception
     flash[:error] = exception.message
     redirect_to new_charge_path
   end
  end

为了解决这些问题，可以将其封装为一个外部服务。

class ChargesController < ApplicationController
 def create
   CheckoutService.new(params).call
   redirect_to charges_path
 rescue Stripe::CardError => exception
   flash[:error] = exception.message
   redirect_to new_charge_path
 end
end

class CheckoutService
 DEFAULT_CURRENCY = 'USD'.freeze

 def initialize(options = {})
   options.each_pair do |key, value|
     instance_variable_set("@#{key}", value)
   end
 end

 def call
   Stripe::Charge.create(charge_attributes)
 end

 private

 attr_reader :email, :source, :amount, :description

 def currency
   @currency || DEFAULT_CURRENCY
 end

 def amount
   @amount.to_i * 100
 end

 def customer
   @customer ||= Stripe::Customer.create(customer_attributes)
 end

 def customer_attributes
   {
     email: email,
     source: source
   }
 end

 def charge_attributes
   {
     customer: customer.id,
     amount: amount,
     description: description,
     currency: currency
   }
 end
end

最终由CheckoutService来负责客户账号的创建和支付，从而解决了 Controller 中业务代码过多的问题。但是，还有一个问题需要解决。如果外部服务抛出异常时（如，信用卡无效）该如何处理，需要重定向的其他页面吗？

class ChargesController < ApplicationController
 def create
   CheckoutService.new(params).call
   redirect_to charges_path
 rescue Stripe::CardError => exception
   flash[:error] = exception.error
   redirect_to new_charge_path
 end
end

为了解决这个问题，可以在一个 Interactor 对象中调用CheckoutService，并捕获可能产生的异常。Interactor 模式常用于封装业务逻辑，每个 Interactor 一般只描述一条业务逻辑。

Interactor 模式通过简单 Ruby 对象（plain old Ruby objects, POROs）可以帮助我们实现单一原则（Single Responsibility Principle, SRP）。Interactor 与 Service Object 类似，只是通常会返回执行状态及相关信息，而且一般会在 Interactor 内部使用 Service Object。下面是该设计模式的使用示例：

class ChargesController < ApplicationController
 def create
   interactor = CheckoutInteractor.call(self)

   if interactor.success?
     redirect_to charges_path
   else
     flash[:error] = interactor.error
     redirect_to new_charge_path
   end
 end
end

class CheckoutInteractor
 def self.call(context)
   interactor = new(context)
   interactor.run
   interactor
 end

 attr_reader :error

 def initialize(context)
   @context = context
 end

 def success?
   @error.nil?
 end

 def run
   CheckoutService.new(context.params)
 rescue Stripe::CardError => exception
   fail!(exception.message)
 end

 private

 attr_reader :context

 def fail!(error)
   @error = error
 end
end

移除所有信用卡错误相关的异常，Controller 就达到了瘦身的目的。瘦身以后，Controller 只负责成功支付和失败支付时的页面跳转。

2. Value Objects

Value Object 设计模式推崇简洁的对象（仅包含一些给定的值），并支持根据给定的逻辑，或基于指定的属性进行对象间相互比较（不基于 id）。Value Object 的例子如，以不同币种表示的货币。我们可以用一个币种（如，美元）来比较这些对象。同样，Value Object 也可以用于表示温度，并可用单位开来进行比较。

示例

假设有一所带电加热的智能房子，加热器可以通过网络接口加以控制。Controller 的一个方法将从温度传感器那里收到指定加热器的参数：温度数值和温度单位（华氏、摄氏或开）。如果是其他温度单位，一律先转换为开。然后，检查温度是否小于 25°C 并大于等于当前温度。

问题分析

Controller 中包含了太多与温度转换和比较相关的逻辑代码。

class AutomatedThermostaticValvesController < ApplicationController
  SCALES = %w(kelvin celsius fahrenheit)
  DEFAULT_SCALE = 'kelvin'
  MAX_TEMPERATURE = 25 + 273.15

  before_action :set_scale

  def heat_up
    was_heat_up = false
    if previous_temperature < next_temperature && next_temperature < MAX_TEMPERATURE
      valve.update(degrees: params[:degrees], scale: params[:scale])
      Heater.call(next_temperature)
      was_heat_up = true
    end
    render json: { was_heat_up: was_heat_up }
  end

  private

  def previous_temperature
    kelvin_degrees_by_scale(valve.degrees, valve.scale)
  end

  def next_temperature
    kelvin_degrees_by_scale(params[:degrees], @scale)
  end

  def set_scale
    @scale = SCALES.include?(params[:scale]) ? params[:scale] : DEFAULT_SCALE
  end

  def valve
    @valve ||= AutomatedThermostaticValve.find(params[:id])
  end

  def kelvin_degrees_by_scale(degrees, scale)
    degrees = degrees.to_f
    case scale.to_s
    when 'kelvin'
      degrees
    when 'celsius'
      degrees + 273.15
    when 'fahrenheit'
      (degrees - 32) * 5 / 9 + 273.15
    end
  end
end

首先，将温度比较逻辑移到 Model 中，Controller 只需要将参数传给`update'方法。但这样一来，Model 就包含了太多温度转换的代码。

class AutomatedThermostaticValvesController < ApplicationController
  def heat_up
    valve.update(next_degrees: params[:degrees], next_scale: params[:scale])

    render json: { was_heat_up: valve.was_heat_up }
  end

  private

  def valve
    @valve ||= AutomatedThermostaticValve.find(params[:id])
  end
end

class AutomatedThermostaticValve < ActiveRecord::Base
  SCALES = %w(kelvin celsius fahrenheit)
  DEFAULT_SCALE = 'kelvin'

  before_validation :check_next_temperature, if: :next_temperature
  after_save :launch_heater, if: :was_heat_up

  attr_accessor :next_degrees, :next_scale
  attr_reader :was_heat_up

  def temperature
    kelvin_degrees_by_scale(degrees, scale)
  end

  def next_temperature
    kelvin_degrees_by_scale(next_degrees, next_scale) if next_degrees.present?
  end

  def max_temperature
    kelvin_degrees_by_scale(25, 'celsius')
  end

  def next_scale=(scale)
    @next_scale = SCALES.include?(scale) ? scale : DEFAULT_SCALE
  end

  private

  def check_next_temperature
    @was_heat_up = false
    if temperature < next_temperature && next_temperature <= max_temperature
      @was_heat_up = true
      assign_attributes(
        degrees: next_degrees,
        scale: next_scale,
      )
    end
    @was_heat_up
  end

  def launch_heater
    Heater.call(temperature)
  end

  def kelvin_degrees_by_scale(degrees, scale)
    degrees = degrees.to_f
    case scale.to_s
    when 'kelvin'
      degrees
    when 'celsius'
      degrees + 273.15
    when 'fahrenheit'
      (degrees - 32) * 5 / 9 + 273.15
    end
  end
end

为了让 Model 瘦身，我们将创建 Value Objects。Value Objects 接受温度数值和温度单位作为初始化参数。在进行比较时，使用<=>操作符比较转换为开之后的温度。

同时，Value Object 也包含一个to_h方法用于批量赋值。另外，还提供了工厂方法from_kelvin、from_celsius和from_fahrenheit，便于以指定单位创建Temperature对象，如Temperature.from_celsius(0)将会创建一个 0°C 或 273°К的温度对象。

class AutomatedThermostaticValvesController < ApplicationController
  def heat_up
    valve.update(next_degrees: params[:degrees], next_scale: params[:scale])
    render json: { was_heat_up: valve.was_heat_up }
  end

  private

  def valve
    @valve ||= AutomatedThermostaticValve.find(params[:id])
  end
end

class AutomatedThermostaticValve < ActiveRecord::Base
  before_validation :check_next_temperature, if: :next_temperature
  after_save :launch_heater, if: :was_heat_up

  attr_accessor :next_degrees, :next_scale
  attr_reader :was_heat_up

  def temperature
    Temperature.new(degrees, scale)
  end

  def temperature=(temperature)
    assign_attributes(temperature.to_h)
  end

  def next_temperature
    Temperature.new(next_degrees, next_scale) if next_degrees.present?
  end

  private

  def check_next_temperature
    @was_heat_up = false
    if temperature < next_temperature && next_temperature <= Temperature::MAX
      self.temperature = next_temperature
      @was_heat_up = true
    end
  end

  def launch_heater
    Heater.call(temperature.kelvin_degrees)
  end
end

class Temperature
  include Comparable
  SCALES = %w(kelvin celsius fahrenheit)
  DEFAULT_SCALE = 'kelvin'

  attr_reader :degrees, :scale, :kelvin_degrees

  def initialize(degrees, scale = 'kelvin')
    @degrees = degrees.to_f
    @scale = case scale
    when *SCALES then scale
    else DEFAULT_SCALE
    end

    @kelvin_degrees = case @scale
    when 'kelvin'
      @degrees
    when 'celsius'
      @degrees + 273.15
    when 'fahrenheit'
      (@degrees - 32) * 5 / 9 + 273.15
    end
  end

  def self.from_celsius(degrees_celsius)
    new(degrees_celsius, 'celsius')
  end

  def self.from_fahrenheit(degrees_fahrenheit)
    new(degrees_celsius, 'fahrenheit')
  end

  def self.from_kelvin(degrees_kelvin)
    new(degrees_kelvin, 'kelvin')
  end

  def <=>(other)
    kelvin_degrees <=> other.kelvin_degrees
  end

  def to_h
    { degrees: degrees, scale: scale }
  end

  MAX = from_celsius(25)
end

最终的结果是，Controller 和 Model 同时得到了瘦身。Controller 不包含任何与温度相关的业务逻辑，Model 也不包含任何与温度转换相关的逻辑，仅调用了Temperature提供的方法。

3. Form Objects

Form Object 模式适用于封装数据校验和持久化。

示例

假设我们有一个典型 Rails Model 和 Controller 用于创建新用户。

问题分析

Model 中包含了所有校验逻辑，因此不能为其他实体重用，如 Admin。

class UsersController < ApplicationController
  def create
    @user = User.new(user_params)

    if @user.save
      render json: @user
    else
      render json: @user.error, status: :unprocessable_entity
    end
  end

  private

  def user_params
    params
      .require(:user)
      .permit(:email, :full_name, :password, :password_confirmation)
  end
end

class User < ActiveRecord::Base
  EMAIL_REGEX = /@/ # Some fancy email regex

  validates :full_name, presence: true
  validates :email, presence: true, format: EMAIL_REGEX
  validates :password, presence: true, confirmation: true
end

解决方案就是将所有校验逻辑移到一个单独负责校验的类中，可以称之为UserForm。

class UserForm
  EMAIL_REGEX = // # Some fancy email regex

  include ActiveModel::Model
  include Virtus.model

  attribute :id, Integer
  attribute :full_name, String
  attribute :email, String
  attribute :password, String
  attribute :password_confirmation, String

  validates :full_name, presence: true
  validates :email, presence: true, format: EMAIL_REGEX
  validates :password, presence: true, confirmation: true

  attr_reader :record

  def persist
    @record = id ? User.find(id) : User.new

    if valid?
      @record.attributes = attributes.except(:password_confirmation, :id)
      @record.save!
      true
    else
      false
    end
  end
end

现在，就可以在 Controller 里面像这样使用它了：

class UsersController < ApplicationController
  def create
    @form = UserForm.new(user_params)

    if @form.persist
      render json: @form.record
    else
      render json: @form.errors, status: :unpocessably_entity
    end
  end

  private

  def user_params
    params.require(:user)
          .permit(:email, :full_name, :password, :password_confirmation)
  end
end

最终，用户 Model 不在负责校验数据：

class User < ActiveRecord::Base
end

4. Query Objects

该模式适用于从 Controller 和 Model 中抽取查询逻辑，并将它封装到可重用的类。

示例

假设我们请求一个文章列表，查询条件是类型为 video、查看数大于 100 并且当前用户可以访问。

问题分析

所有查询逻辑都在 Controller 中（即所有查询条件都在 Controller 中添加）。

不可重用
难于测试
文章 Scheme 的任何改变都可能影响这段代码

class Article < ActiveRecord::Base
    # t.string :status
    # t.string :type
    # t.integer :view_count
  end

 class ArticlesController < ApplicationController
    def index
      @articles = Article
                  .accessible_by(current_ability)
                  .where(type: :video)
                  .where('view_count > ?', 100)
    end
  end

重构的第一步就是封装查询条件，提供简洁的 API 接口。在 Rails 中，可以使用 scope 实现：

class Article < ActiveRecord::Base
  scope :with_video_type, -> { where(type: :video) }
  scope :popular, -> { where('view_count > ?', 100) }
  scope :popular_with_video_type, -> { popular.with_video_type }
end

现在就可以使用这些简洁的 API 接口来查询，而不用关心底层是如何实现的。如果 article 的 scheme 发生了改变，仅需要修改 article 类即可。

class ArticlesController < ApplicationController 
  def index 
    @articles = Article 
                .accessible_by(current_ability) 
                .popular_with_video_type 
  end
end

看起来不错，不过又有一些新问题出现了。首先，需要为每个想要封装的查询条件创建 scope，最终会导致 Model 中充斥诸多针对不同应用场景的 scope 组合。其次，scope 不能在不同的 model 中重用，比如不用使用 Article 的 scope 来查询 Attachment。最后，将所有查询相关的逻辑都塞到 Article 类中也违反了单一原则。解决方案是使用 Query Object。

class PopularVideoQuery 
  def call(relation) 
    relation 
      .where(type: :video) 
      .where('view_count > ?', 100) 
  end
end

class ArticlesController < ApplicationController 
  def index 
    relation = Article.accessible_by(current_ability) 
    @articles = PopularVideoQuery.new.call(relation) 
  end
end

哈，这样就可以做到重用了！现在可以将它用于查询任何具有相似 scheme 的类了：

class Attachment < ActiveRecord::Base 
  # t.string :type 
  # t.integer :view_count
end

PopularVideoQuery.new.call(Attachment.all).to_sql
# "SELECT \"attachments\".* FROM \"attachments\" WHERE \"attachments\".\"type\" = 'video' AND (view_count > 100)"
PopularVideoQuery.new.call(Article.all).to_sql
# "SELECT \"articles\".* FROM \"articles\" WHERE \"articles\".\"type\" = 'video' AND (view_count > 100)"

如果想进一步支持链式调用的话，也很简单。只需要让call方法遵循ActiveRecord::Relation接口即可：

class BaseQuery
  def |(other)
    ChainedQuery.new do |relation|
      other.call(call(relation))
    end
  end
end

class ChainedQuery < BaseQuery
  def initialize(&block)
    @block = block
  end

  def call(relation)
    @block.call(relation)
  end
end

class WithStatusQuery < BaseQuery
  def initialize(status)
    @status = status
  end

  def call(relation)
    relation.where(status: @status)
  end
end

query = WithStatusQuery.new(:published) | PopularVideoQuery.new
query.call(Article.all).to_sql
# "SELECT \"articles\".* FROM \"articles\" WHERE \"articles\".\"status\" = 'published' AND \"articles\".\"type\" = 'video' AND (view_count > 100)"

现在，我们得到了一个封装所有查询逻辑，可重用，提供简洁接口并易于测试的类。

5. View Objects (Serializer/Presenter)

View Object 适用于将 View 中的数据及相关计算从 Controller 和 Model 抽离出来，如一个网站的 HTML 页面或 API 终端请求的 JSON 响应。

示例

View 中一般通常存在以下计算：

根据服务器协议和图片路径创建图片 URL
获取文章的标题和描述，如果没有返回默认值
连接姓和名来显示全名
用合适的方式显示文章的创建日期

问题分析

View 中包含了太多计算逻辑。

# 重构之前
#/app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
 def show
   @article = Article.find(params[:id])
 end
end

#/app/views/articles/show.html.erb
<% content_for :header do %>
 <title>
     <%= @article.title_for_head_tag || I18n.t('default_title_for_head') %>
 </title>
 <meta name='description' content="<%= @article.description_for_head_tag || I18n.t('default_description_for_head') %>">
  <meta property="og:type" content="article">
  <meta property="og:title" content="<%= @article.title %>">
  <% if @article.description_for_head_tag %>
    <meta property="og:description" content="<%= @article.description_for_head_tag %>">
  <% end %>
  <% if @article.image %>
     <meta property="og:image" content="<%= "#{request.protocol}#{request.host_with_port}#{@article.main_image}" %>">
  <% end %>
<% end %>

<% if @article.image %>
 <%= image_tag @article.image.url %>
<% else %>
 <%= image_tag 'no-image.png'%>
<% end %>
<h1>
 <%= @article.title %>
</h1>

<p>
 <%= @article.text %>
</p>

<% if @article.author %>
<p>
 <%= "#{@article.author.first_name} #{@article.author.last_name}" %>
</p>
<%end%>

<p>
 <%= t('date') %>
 <%= @article.created_at.strftime("%B %e, %Y")%>
</p>

为了解决这个问题，可以先创建一个 presenter 基类，然后再创建一个ArticlePresenter类的实例。ArticlePresenter方法根据适当的计算返回想要的标签。

#/app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
 def show
   @article = Article.find(params[:id])
 end
end

#/app/presenters/base_presenter.rb
class BasePresenter
 def initialize(object, template)
   @object = object
   @template = template
 end

 def self.presents(name)
   define_method(name) do
     @object
   end
 end

 def h
   @template
 end
end

#/app/helpers/application_helper.rb
module ApplicationHelper
  def presenter(model)
    klass = "#{model.class}Presenter".constantize
    presenter = klass.new(model, self)
    yield(presenter) if block_given?
  end
end

#/app/presenters/article_presenters.rb
class ArticlePresenter < BasePresenter
 presents :article
 delegate :title, :text, to: :article

 def meta_title
   title = article.title_for_head_tag || I18n.t('default_title_for_head')
   h.content_tag :title, title
 end

 def meta_description
   description = article.description_for_head_tag || I18n.t('default_description_for_head')
   h.content_tag :meta, nil, content: description
 end

 def og_type
   open_graph_meta "article", "og:type"
 end
  def og_title
   open_graph_meta "og:title", article.title
 end

 def og_description
   open_graph_meta "og:description", article.description_for_head_tag if article.description_for_head_tag
 end

 def og_image
   if article.image
     image = "#{request.protocol}#{request.host_with_port}#{article.main_image}"
     open_graph_meta "og:image", image
   end
 end

 def author_name
   if article.author
     h.content_tag :p, "#{article.author.first_name} #{article.author.last_name}"
   end
 end

 def image
  if article.image
    h.image_tag article.image.url
  else
     h.image_tag 'no-image.png'
  end
 end

 private
 def open_graph_meta content, property
   h.content_tag :meta, nil, content: content, property: property
 end
end

现在 View 中不包含任何与计算相关的逻辑，所有组件都抽离到了 presenter 中，并可在其他 View 中重用，如下：

#/app/views/articles/show.html.erb
<% presenter @article do |article_presenter| %>
 <% content_for :header do %>
   <%= article_presenter.meta_title %>
   <%= article_presenter.meta_description %>
   <%= article_presenter.og_type %>
   <%= article_presenter.og_title %>
   <%= article_presenter.og_description %>
   <%= article_presenter.og_image %>
 <% end %>

 <%= article_presenter.image%>
 <h1> <%= article_presenter.title %> </h1>
 <p>  <%= article_presenter.text %> </p>
 <%= article_presenter.author_name %>
<% end %>

6. Policy Objects

Policy Object 模式与 Service Object 模式相似，前者负责读操作，后者负责写操作。Policy Object 模式适用于封装复杂的业务规则，并易于替换。比如，可以使用一个访客 Policy Object 来识别一个访客是否可以访问某些特定资源。当用户是管理员时，可以很方便的将访客 Policy Object 替换为包含管理员规则的管理员 Policy Object。

示例

在用户创建一个项目之前，Controller 将检查当前用户是否为管理者，是否有权限创建项目，当前用户项目数量是否小于最大值，以及在 Redis 中是否存在阻塞的项目创建。

问题分析

自由 Controller 知道项目创建的规则
Controller 包含了额外的逻辑代码

class ProjectsController < ApplicationController
   def create
     if can_create_project?
       @project = Project.create!(project_params)
       render json: @project, status: :created
     else
       head :unauthorized
     end
   end

  private

  def can_create_project?
     current_user.manager? &&
       current_user.projects.count < Project.max_count &&
       redis.get('projects_creation_blocked') != '1'
   end

  def project_params
     params.require(:project).permit(:name, :description)
  end

  def redis
    Redis.current
  end
end

class User < ActiveRecord::Base
  enum role: [:manager, :employee, :guest]
end

为了让 Controller 瘦身，可以将规则代码移到 Model 中。所有检查逻辑都将移出 Controller。但是这样一来，User 类就知道了 Redis 和 Project 类的逻辑。并且 Model 也变胖了。

class User < ActiveRecord::Base
  enum role: [:manager, :employee, :guest]

  def can_create_project?
    manager? &&
      projects.count < Project.max_count &&
        redis.get('projects_creation_blocked') != '1'
  end

  private

  def redis
    Redis.current
  end
end

class ProjectsController < ApplicationController
  def create
    if current_user.can_create_project?
       @project = Project.create!(project_params)
       render json: @project, status: :created
    else
       head :unauthorized
    end
  end

  private

  def project_params
     params.require(:project).permit(:name, :description)
  end
end

在这种情况下，可以将这些规则抽取到一个 Policy Object 中，从而使 Controller 和 Model 同时瘦身。

class CreateProjectPolicy
  def initialize(user, redis_client)
    @user = user
    @redis_client = redis_client
  end

  def allowed?
    @user.manager? && below_project_limit && !project_creation_blocked
  end

 private

  def below_project_limit
    @user.projects.count < Project.max_count
  end

  def project_creation_blocked
    @redis_client.get('projects_creation_blocked') == '1'
  end
end

class ProjectsController < ApplicationController
  def create
    if policy.allowed?
       @project = Project.create!(project_params)
       render json: @project, status: :created
     else
       head :unauthorized
     end
  end

  private

  def project_params
     params.require(:project).permit(:name, :description)
  end

  def policy
     CreateProjectPolicy.new(current_user, redis)
  end

  def redis
     Redis.current
  end
end

def User < ActiveRecord::Base
   enum role: [:manager, :employee, :guest]
end

最终的结果是一个干净的 Controller 和 Model。Policy Object 封装了所有权限检查逻辑，并且所有外部依赖都从 Controller 注入到 Policy Object 中。所有的类都各司其职。

7. Decorators

Decorator 模式允许我们给某个类的实例添加各种辅助行为，而不影响相同类的其他实例。该设计模式广泛用于在不同类之间划分功能，也可以用来替代继承以遵循单一原则。

示例

假设 View 中存在许多计算：

根据title_for_head是否有值显示不同的标题
如果缺少车图片，那么显示一张默认的车图片
如果车的品牌、类型、说明、车主、城市和联系电话未设置时，显示默认值
展示车的状态
显示格式化后的车的创建日期

问题分析

View 中包含了过多的计算逻辑：

#/app/controllers/cars_controller.rb
class CarsController < ApplicationController
 def show
   @car = Car.find(params[:id])
 end
end

#/app/views/cars/show.html.erb
<% content_for :header do %>
 <title>
   <% if @car.title_for_head %>
     <%="#{ @car.title_for_head } | #{t('beautiful_cars')}" %>
   <% else %>
     <%= t('beautiful_cars') %>
   <% end %>
 </title>
 <% if @car.description_for_head%>
   <meta name='description' content= "#{<%= @car.description_for_head %>}">
 <% end %>
<% end %>

<% if @car.image %>
 <%= image_tag @car.image.url %>
<% else %>
 <%= image_tag 'no-images.png'%>
<% end %>
<h1>
 <%= t('brand') %>
 <% if @car.brand %>
   <%= @car.brand %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</h1>

<p>
 <%= t('model') %>
 <% if @car.model %>
   <%= @car.model %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</p>

<p>
 <%= t('notes') %>
 <% if @car.notes %>
   <%= @car.notes %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</p>

<p>
 <%= t('owner') %>
 <% if @car.owner %>
   <%= @car.owner %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</p>

<p>
 <%= t('city') %>
 <% if @car.city %>
   <%= @car.city %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</p>
<p>
 <%= t('owner_phone') %>
 <% if @car.phone %>
   <%= @car.phone %>
 <% else %>
    <%= t('undefined') %>
 <% end %>
</p>

<p>
 <%= t('state') %>
 <% if @car.used %>
   <%= t('used') %>
 <% else %>
   <%= t('new') %>
 <% end %>
</p>

<p>
 <%= t('date') %>
 <%= @car.created_at.strftime("%B %e, %Y")%>
</p>

可以使用 Draper 这个装饰 gem，将所有逻辑抽取到CarDecorator中。

#/app/controllers/cars_controller.rb
class CarsController < ApplicationController
 def show
   @car = Car.find(params[:id]).decorate
 end
end

#/app/decorators/car_decorator.rb
class CarDecorator < Draper::Decorator
 delegate_all

 def meta_title
   result =
     if object.title_for_head
       "#{ object.title_for_head } | #{I18n.t('beautiful_cars')}"
     else
       t('beautiful_cars')
     end
   h.content_tag :title, result
 end

 def meta_description
   if object.description_for_head
     h.content_tag :meta, nil ,content: object.description_for_head
   end
 end

 def image
   result = object.image.url.present? ? object.image.url : 'no-images.png'
   h.image_tag result
 end

 def brand
   get_info object.brand
 end

 def model
   get_info object.model
 end

 def notes
   get_info object.notes
 end

 def owner
   get_info object.owner
 end

 def city
   get_info object.city
 end

 def owner_phone
   get_info object.phone
 end

 def state
   object.used ? I18n.t('used') : I18n.t('new')
 end

 def created_at
   object.created_at.strftime("%B %e, %Y")
 end

 private

 def get_info value
   value.present? ? value : t('undefined')
 end
end

改造后不包含任何计算的整洁 View：

#/app/views/cars/show.html.erb
<% content_for :header do %>
 <%= @car.meta_title %>
 <%= @car.meta_description%>
<% end %>

<%= @car.image %>
<h1> <%= t('brand') %> <%= @car.brand %> </h1>
<p> <%= t('model') %> <%= @car.model %>  </p>
<p> <%= t('notes') %> <%= @car.notes %>  </p>
<p> <%= t('owner') %> <%= @car.owner %>  </p>
<p> <%= t('city') %> <%= @car.city %>    </p>
<p> <%= t('owner_phone') %> <%= @car.phone %> </p>
<p> <%= t('state') %> <%= @car.state %>   </p>
<p> <%= t('date') %> <%= @car.created_at%> </p>

总结

相信如上这些概念将有助于你了解在何时以及如何重构代码。这些工具可以帮助你有效的管理代码的复杂度。其实，在开发的最初就应该小心地规划代码逻辑的组织，这样就可以避免之后在重构上花费大量时间。

[讨论] 大量 String 判断式的重构方法

artone — Tue, 15 Nov 2016 14:52:02 +0800

Dash for iOS open source 了，先来看看里面这段精美的 if statement：

图片来源：Twitter

虽说我不会写 Objective-C，不过如果在 Ruby 上遇到应该我会这样写：

if [
    "bash",
    "Chai",
    "D3JS",
    "Go",
    "Javascript",
    "Ruby",
].include? platform

  # do something

end

阵列内容可以按照字母排序，肉眼看也比较容易阅读。大家都怎么写呢？

这一段 slim 代码有办法优化吗？

leopku — Fri, 21 Oct 2016 16:59:34 +0800

.tile.is-ancestor
  .tile.is-3.is-vertical
    .tile.is-parent.is-vertical
      - @projects.each_with_index do |project, index|
        - if index % 4 == 0
          .title.is-child.box
            p.title = index

  .tile.is-3.is-vertical
    .tile.is-parent.is-vertical
      - @projects.each_with_index do |project, index|
        - if index % 4 == 1
          .title.is-child.box
            p.title = index

  .tile.is-3.is-vertical
    .tile.is-parent.is-vertical
      - @projects.each_with_index do |project, index|
        - if index % 4 == 2
          .title.is-child.box
            p.title = index

  .tile.is-3.is-vertical
    .tile.is-parent.is-vertical
      - @projects.each_with_index do |project, index|
        - if index % 4 == 3
          .title.is-child.box
            p.title = index

干掉你代码中的坏味道

ane — Fri, 05 Aug 2016 17:00:44 +0800

最近团队开始抓代码质量了，总结一下自己的经验，先看看坏代码有哪些特点：

“幸福的家庭都一样，不幸的家庭却各有不同”，这句话放到代码里也同样适用。接下来，我们聊一聊如何解决坏代码问题。

如果我问你，“你们是如何保证团队代码质量的”，你的回答可能是：“我们每次写完代码，都会花一些时间 review 一下。”

恩，做的确实不错，但是，做的还不够，除非你是门门考试都 100 的学霸，否则，借助一些工具还是比较稳妥的办法。

在这里简单介绍一个代码分析工具 RubyCritic，这是一个专门针对 Ruby 的一个静态代码分析工具。其它语言的，也有相似功能的工具链，我就不做介绍了。

这是一个命令行工具，第一步就是添加到你的 gem 库中，当然，还可以使用 guard 自动化分析。（Ruby 的世界，你懂得~）第二 step，在 console 运行【RubyCritic】命令，就像这样：

在命令的最后，会生成一个静态页面。长这个样子：

x 轴代表改动频率，Y 轴代表代码复杂程度

这是分析结果的 overview，超过 200 的复杂度的，基本都是坏代码。

再看看 code 里的内容：

对不同文件按照改动频率、复杂度、重复度和坏味道 4 个维度进行综合评定代码质量等级（和美国考试的成绩打分规则一样）。

RubyCritic 对代码分析的原理，其实就是分析一些，被它认为是坏代码的点。注意，我这里使用的措辞是“被它认为，所以，有时候，它不是绝对的正确。”还可以查看具体的类文件中的代码质量问题。

更多的介绍，详见 https://github.com/whitesmith/rubycritic

下面，我们针对 RubyCritic 给我们的一些坏代码的点，有针对性的做些代码调整。

这里使用 git diff 比较新旧版本的差异。operator 原来是实例方法，代码行 7，并且里面还有一个 if 结构体。started_time_and_node 原来是实例方法，代码行 4，并且里面还不止一个 if 结构体。

笔者 review 的方式：

1.实例方法修改为类方法（减少混入方法，解耦合，减低负责度）

2.多使用 Ruby 原生链式操作（减少中间变量，更少的代码，对于脚本语言，就是更快的执行效率，而且很多原生方法是 C 语言实现。）

3.去掉结构体（现代编程语言的结构体，让代码具有丰富的逻辑性和可读性，但是缺点就是 cpu 的额外开销。）

以上部分，属于语法层面的奇技淫巧。

第二部分，我们从设计角度分析一下。

它的代码行只有 141 行，方法也只有 7 个。但是评级却是 C。再看看代码分析细节，这里就展现一小部分，简直就是惨不忍睹，不好意思全展现给大家看了。

没有人会一开始就这样写代码，这种坏代码，永远都是渐渐变馊的。不过笔记仔细想来，当年遇到过比着还馊 1000 倍的代码（1000 倍都不算过分）。

这是笔者做的第一版重构结果。

这里使用了策略模式。Stats_hash 不再是充当一个集合的作用，现在变成了一个环境类，将原来依赖 if 结构数据分装到不同的行为类中。

第二版的改动计划是，引入 work-job 的模式，并发执行 4 个 job。

第三版改动计划就是利用回调方式，去掉与该类不相干的代码，将逻辑分装到行为类里。

好了，写到这里，基本的代码层面的优化思路就这些了，其它就是开支散叶的过程，这里就不冗余了。下一节，咱俩聊一聊性能优化的一些思路。

Ruby China 社区 重构 节点

聊聊代码的复杂性

复杂从哪来

如何解决

脚注

后台系统重构 - 菜单同步

需求

请求路由定义

菜单改成可配置化

旧系统菜单渲染

新系统菜单渲染

其他

目前程序已经开发了一年，想要有 2.0 版本的规划，怎么去做设计书

一款成功的全球服游戏该如何进行架构选型与设计

TestProf

反模式之虚拟模型模式及其应用

前言

应用

反模式

前置知识

ActiveModel

虚拟模型

ActiveRecord::Attributes::ClassMethods#attribute

ActiveRecord::AttributeMethods::Serialization#serialize

考虑：有几种固定类型的商品，不同类型的商品有不同的商品参数

一种可行的传统做法

另一种可行的做法：AR#serialize + 虚拟模型

比较

再考虑：商品类型由运营管理，商品参数也由运营设置

传统做法

技巧：动态模型类生成

另一种可行的做法：动态虚拟模型生成

坑：model_name

示例：FormCore

DuckRecord

其他应用：RoleCore

将现有的 model 的 pk 从 bigint 的 id 变为 uuid, 是放在 migration 还是 task 中比较好.

步骤如下

Rails 并发发送请求问题请教

如何从 MongoDB 迁移到 MySQL

从关系到文档

从文档到关系

数据的预处理

Mongoid 的『小兄弟』们

主键与 UUID

代码的迁移

数据的迁移

多对多关系的处理

测试的重要性

总结

Reference

用 Rails 写 API 服务，性能感觉不足，怎么办？

Routes 文件模块太多，想把定义的 admin、account、site 等等模块分别在不同文件里写，有方法吗？

多个 Rails 项目中都会用到的代码，怎样抽象更加方便管理更新？

最近在选型基础平台，求建议

这种代码有什么好的重构方法吗？

常见重构手法 (下)

Common Reactor Skills Part Two

Agenda

Agenda

改善空间？

Replace Magic number with Constant(用常量替换魔法数)

思考 - 放置常量的位置？

字符串字面量与魔法数的异同？

和魔法数的异同？

改善空间？

Decompose Conditional(分解条件表达式)

最容易从以下代码结构联想到什么？

改善空间？

if-else 结构意味着什么？

Guard Clauses（卫语句）

卫语句意味着什么？

何时使才用 if-else？

影响选用 if-else/卫语句的因数

-- 主要观察点：两个分支是否都是正常情况

影响选用 if-else/卫语句的因数

-- 主要观察点：两个分支代码量是否相当

Replace Nested Conditional with Guard Clauses (用卫语句替换嵌套条件表达式)

消除条件嵌套

条件取反 -- 识别异常情况

Ruby China 社区重构节点