qinfanpeng (qinfanpeng)

拒绝高考冲刺 12 年，志愿填写 12 分

qinfanpeng — Sat, 10 Jun 2017 23:52:07 +0800

前些天和朋友聊天，回想起我们当年填志愿啥都不懂，看着顺眼就填了，想想挺后怕的。不少考生辛辛苦苦冲刺高考 12 年，但填志愿的准备工作却不足 12 小时，甚至是 12 分钟，此诚不可谓不轻率。对很多人而言，选择高考志愿专业，就意味着选择自己大半生的职业（不从事本专业的，很大程度上意味着你大学的失败）。对于这样一件人生大事来说，怎能不好好筹划，谋定而后动呢。正好身边也有朋友就因志愿没填好，过得很不如意。故此整理此文，希望能帮到一些朋友。

选专业的常见错误

看着顺眼
七大姑八大姨推荐，工资高（比如因为某亲戚是包工头就学建筑）
根据自己的『兴趣』来，如：
- 因为会五笔输入法，就选计算器专业
- 因为喜欢打游戏，就选计算专业

多方打听、结合自己的兴趣填志愿是好事，但很多人缺乏进一步深入调研、了解，极易乱选。比如有位朋友因为以前会用五笔输入法就选了计算机专业，到了大学发现计算机专业和五笔输入法关系并不大，上课听不懂、提不起兴趣，恍惚度日。相当于四年大学白度了，最终不得不重新换行业找工作。那么什么才算是有深入了解呢，至少得知道该专业具体是干什么的吧，要修些什么课程，毕业后一般从事哪些工作，工作内容是啥等。

挑选候选专业

如果你已有明确、清晰的专业兴趣，且按照『审视候选专业』审视完后，依然钟爱它、觉得很适合你，那大胆地选它吧，即使它很冷门，相信兴趣使然，你依然能做好的。如果你无明确方法和兴趣，那么建议从以下方面来考虑：

就业
收入
国家发展趋势

审视候选专业

该部分以『车辆工程』专业为例，仅供示例使用，不代表任何个人观点。另外，该部分涉及很多网收集信息过程，注意防骗。

大体了解候选专业

在浏览器地址栏输入网址“https://www.baidu.com/”
在搜索框输入关键字“车辆工程百科”
点击搜索结果进入
将第 2 步中的关键字改成“车辆工程”，搜索更多内容

了解候选专业所学课程

通过上面的步骤一般都可以找到专业需要修的课程了，比如这里：要是没找到的话，试试在百度搜索框里输入“车辆工程课程”。

下面以《汽车构造》为例，在百度搜索框搜索“《汽车构造》公开课”或“《汽车构造》视频”，一般都能找到。进去试着听听，听不懂不要紧，关键感受一下，确定是不是你原来想象的那样，是不是你感兴趣的。

了解候选专业相关工作

在百度搜索“智联招聘”，如图所示（注意绕开其中的广告）：在智联招聘中搜索“车辆工程”，工作经验选 1-3 年（这样更逼真），然后可以试着把第一页的职位要求、工作内容都通读一篇，反复确人是不是你想要的。你还可以进一步在在百度上搜索某工作的工作内容，比如“CAE 疲劳分析工程师工作内容”。

如何填报第二志愿

这部分很不好把握，建议多花心思。推荐阅读：

重要参考资料

我这里主要主要说明如何挑选候选专业，但还有其他方面也很重要，比如“学校和专业哪个更重要”、“同等学校如何选城市”、“如何把握国家发展趋势”等，建议收听或观看：

[译] React setState 的麻烦事儿

qinfanpeng — Thu, 06 Apr 2017 19:58:46 +0800

原文地址：setState() Gate

原文作者：Eric Elliott

译文出自：掘金翻译计划

译者：reid3290

校对者：1992chenlu，qinfanpeng

setState() 门事件

React setState() 解惑

译注：本文起因于作者的一条推特，他认为应该避免使用 setState()，随后引发论战，遂写此文详细阐明其观点。译者个人认为，本文主要在于“撕逼“，并未深入介绍 setState() 的技术细节，希望从技术层面深入了解 setState() 的同学可以参考[译] React 未来之函数式 setState。对 setState() 不了解的同学可能会感到本文不知所云，特此说明。

一切都源于上周。3 位 React 初学者尝试在项目中使用 setState() 时遇到了 3 种不同的问题。我指导过很多 React 新手，也为团队提供从其他技术到 React 的架构转型咨询。

其中一位初学者正在开发一个十分适合使用 Redux 的生产项目，所以我没有正面去解决 setState() 的同步问题（the timing with setState()），而是直接建议他用 Redux 替换掉 setState()，因为使用 Redux 能避免 state 在组件渲染的过程中发生改变。Redux 简单地利用来自 store 的 props 来决定如何渲染界面，巧妙地规避了复杂的同步问题。

因此也就有了下面这条推特：

“React 有个 setState() 问题：让新手使用 setState() 毫无好处（a recipe for headaches）。高手们已经学会了如何避免使用它"

之后，有些高手就来纠正我了：

“我是 React 团队的一员。在尝试其他方法之前，请学会使用 setState。”

“那些所谓‘高手’们怕是要落伍了，因为 React 17 将会默认采用异步调度。”

对于第二点：

“Fiber 有一种用于暂停、切分、重建和取消更新的策略，但如果你脱离了组件 state，那此策略便无法正常工作了。”

貌似都没错，可是码农们就要骂娘了：

面对困境“呵呵”两下并无妨，不过千万别呵呵过后就对问题视而不见了。

在和另一个初学者交流的时候，我发现他也对 setState() 的工作机制感到困惑。他后来索性放弃了，他把 state 塞在一个闭包里；显而易见，闭包中 state 的改变是不会触发 render 函数自动执行的。

考虑到深感困惑的初学者之多，我还是坚持我上述推文中前半句的观点；但如果可以重来的话，我会对后半句稍作修改，因为确有很多高手在（主要是 Facebook 和 Netfix 的工程师）大量地使用 setState()：

“React 有个 setState() 问题：叫新手使用 setState() 毫无好处，但高手们自有神技。“

当然，推特还是有可能会丧失其集体智慧（lose its collective mind）（译注：个人认为这句应该是指当网络上大多数人持某一观点时，那即使该观点是错的，那你也不能指出其错误，否则就会招致集体攻讦；或者说，真理有时候只掌握在少数人手里）。毕竟，React 是“完美的”，我们都必须承认 setState的美妙优雅是多么的恰如其分，否则只会遭到冷嘲热讽。

如果 setState() 令你感到困惑，那都是你的问题 —— 你要么是疯子，要么是傻瓜。（我好像忘了说 Javascript 社区的霸凌问题了）

好了，当你嘲笑所有初学者的时候，先反省反省自己吧，别以为掌握了 setState() 就可以得意忘形了。

那种行为是荒谬可笑的，是精英主义论的，会让新手们感到十分讨厌。如果人们经常对某个 API 感到困惑的话，那就该改进 API 本身的设计了，或者至少应该改进下文档。

让我们的社区和工具变得更加友好对所有人来说都是件好事。

setState() 究竟有何问题？

这个问题可以有两个答案：

没啥问题。（大部分情况下）其表现和设计期望一样，足以解决目标问题。
学习曲线问题。对新手而言，一些用原生 JS 和直接的 DOM 操作可以轻松实现的效果，用 React 和 setState 实现起来就会困难重重。

React 的设计初衷本是简化应用开发流程，但是：

你却不能随心所欲地操作 DOM。
你不能随心所欲地（于任何时间、依赖任意数据源）更新 state。
在组件的生命周期中，你并不总是能在屏幕上直接观察到渲染后的 DOM 元素，这限制了 setState() 的使用时机和方式（因为你有些 state 可能还没有渲染到屏幕上）。

在这几种情况下，困惑都来源于 React 组件生命周期的限制性（这些限制是刻意设计的，是好的）。

从属 State（Dependent State）

更新 state 时，更新结果可能依赖于：

当前 state
同一批次中先前的更新操作
当前已渲染的 DOM（例如：组件的坐标位置、可见性、CSS 计算值等等）

当存在这几种从属 state 的时候，如果你还想简单直接地更新 state，那 React 的表现行为会让你大吃一惊，并且是以一种令人憎恶又难以调试的方式。大多数情况下，你的代码根本无法工作：要么 state 不对，要么控制台有错误。

我之所以吐槽 setState()，是因为它的这种限制性在 API 文档中并没有详细说明，关于应对这种限制性的各种通用模式也未能阐述清楚。这迫使初学者只能不断试错、Google 或者从其他社区成员那里寻求帮助，但实际上在文档中本该就有更好的新手指南。

当前关于 setState() 的文档开头如下：

setState(nextState, callback)

将 nextState 浅合并到当前 state。这是在事件处理函数和服务器请求回调函数中触发 UI 更新的主要方法。

在末尾确实也提到了其异步行为：

不保证 setState 调用会同步执行，考虑到性能问题，可能会对多次调用作批处理。

这就是很多用户层（userland）bug 的根本原因：

// 假设 state.count === 0
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
// state.count === 1, 而不是 3

本质上等同于：

Object.assign(state,
  {count: state.count + 1},
  {count: state.count + 1},
  {count: state.count + 1}
); // {count: 1}

这在文档中并未显式说明（在另外一份特殊指南中提到了）。

文档还提到了另外一种函数式的 setState() 语法：

也可以传递一个签名为 function(state, props) => newState 的函数作为参数。这会将一个原子性的更新操作加入更新队列，在设置任何值之前，此操作会查询前一刻的 state 和 props。

...

setState() 并不会立即改变 this.state ，而是会创建一个待执行的变动。调用此方法后访问 this.state 有可能会得到当前已存在的 state（译注：指 state 尚未来得及改变）。

API 文档虽提供了些许线索，但未能以一种清晰明了的方式阐明初学者经常遇到的怪异表现。开发模式下，尽管 React 的错误信息以有效、准确著称，但当 setState() 的同步问题出现 bug 的时候控制台却没有任何警告。

StackOverflow 上有关 setState() 的问题大都要归结于组件的生命周期问题。毫无疑问，React 非常流行，因此那些问题都被问烂了，也有着各种良莠不齐的回答。

那么，初学者究竟该如何掌握 setState() 呢？

在 React 的文档中还有一份名为 “state 和生命周期”的指南，该指南提供了更多深入内容：

“…要解决此问题，请使用 setState() 的第二种形式 —— 以一个函数而不是对象作为参数，此函数的第一个参数是前一刻的 state，第二个参数是 state 更新执行瞬间的 props：”

// 正确用法
this.setState((prevState, props) => ({
  count: prevState.count + props.increment
}));

这个函数参数形式（有时被称为“函数式 setState()”）的工作机制更像：

[
  {increment: 1},
  {increment: 1},
  {increment: 1}
].reduce((prevState, props) => ({
  count: prevState.count + props.increment
}), {count: 0}); // {count: 3}

不明白 reduce 的工作机制？参见 “Composing Software” 的 “Reduce” 教程。

关键点在于更新函数（updater function）：

(prevState, props) => ({
  count: prevState.count + props.increment
})

这基本上就是个 reducer，其中 prevState 类似于一个累加器（accumulator），而 props 则像是新的数据源。类似于 Redux 中的 reducers，你可以使用任何标准的 reduce 工具库对该函数进行 reduce（包括 Array.prototype.reduce()）。同样类似于 Redux，reducer 应该是纯函数。

注意：企图直接修改 prevState 通常都是初学者困惑的根源。

API 文档中并未提及更新函数的这些特性和要求，所以，即使少数幸运的初学者碰巧了解到函数式 setState() 可以实现一些对象字面量形式无法实现的功能，最终依然可能困惑不解。

仅仅是新手才有的问题吗？

直到现在，在处理表单或是 DOM 元素坐标位置的时候，我还是会时不时得掉到坑里去。当你使用 setState() 的时候，你必须直接面对组件生命周期的相关问题；但当你使用容器组件或是通过 props 来存储和传递 state 的时候，React 则会替你处理同步问题。

无论你有经验与否 ，处理共享的可变 state 和 state 锁（state locks）都是很棘手的。经验丰富之人只不过是能更加快速地定位问题，然后找出一个巧妙的变通方案罢了。

因为初学者从未遇到过这种问题，更不知规避方案，所以是掉坑里摔得最惨的。

当问题发生时，你当然可以选择和 React 斗个你死我活；不过，你也可以选择让 React 顺其自然的工作。这就是我说即使是对初学者而言，Redux 有时都比 setState 更简单的原因。

在并发系统中，state 更新通常按其中一种方式进行：

当其他程序（或代码）正在访问 state 时，禁止 state 的更新（例如 setState()）（译注：即常见的锁机制）
引入不可变性来消除共享的可变 state，从而实现对 state 的无限制访问，并且可以在任何时间创建新 state（例如 Redux）

在我看来（在向很多学生教授过这两种方法之后），相比于第二种方法，第一种方法更加容易导致错误，也更加容易令人困惑。当 state 更新被简单地阻塞时（在 setState 的例子中，也可以叫批处理化或延迟执行），解决问题的正确方法并不十分清晰明了。

当遇到 setState() 的同步问题时，我的直觉反应其实是很简单的：将 state 的管理上移到 Redux（或 MobX）或容器组件中。基于多方面原因，我自己使用同时也推荐他人使用 Redux，但很显然，这并不是一条放之四海而皆准的建议。

Redux 自有其陡峭的学习曲线，但它规避了共享的可变 state 以及 state 更新同步等复杂问题。因此我发现，一旦我教会了学生如何避免可变性，接下来基本就一帆风顺了。

对于没有任何函数式编程经验的新手而言，学习 Redux 遇到的问题可能会比学习 setState() 遇到的更多 —— 但是，Redux 至少有很多其作者亲自讲授的免费教程

React 应当向 Redux 学习：有关 React 编程模式和 setState() 踩坑的视频教程定能让 React 主页锦上添花。

在渲染之前决定 State

将 state 管理移到容器组件（或 Redux）中能促使你从另一个角度思考组件 state 问题，因为这种情况下，在组件渲染之前，其** state 必须是既定的**（因为你必须将其作为 props 传下去）。

重要的事情说三遍：

渲染之前，决定 state！

渲染之前，决定 state！

渲染之前，决定 state！

说完三篇之后就可以得到一个显然的推论：在 render() 函数中调用 setState() 是反模式的。

在 render 函数中计算从属 state 是 OK 的（比如说，state 中有 firstName 和 lastName，据此你计算出 fullName，在 render 函数中这样做完全是 OK 的），但我还是倾向于在容器组件中计算出从属 state，然后通过 props 将其传递给展示组件（presentation components）。

setState() 该怎么治？

我倾向于废弃掉对象字面量形式的 setState()，我知道这（表面上看）更加易于理解也更加方便（译者：“这”指对象字面量形式的 setState()），但它也是坑之所在啊。用脚指头都能猜到，肯定有人这样写：

state.count; // 0
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});

然后天真就地以为 {count: 3}。批量化处理后对象的同名 props 被合并掉的情况几乎不可能是用户所期望的行为，反正我是没见过这种例子。要是真存在这种情况，那我必须说这跟 React 的实现细节耦合地太紧密了，根本不能作为有效参考用例。

我也希望 API 文档中有关 setState() 的章节能够加上“state 和声明周期”这一深度指南的链接，这能给那些想要全面学习 setState() 的用户更多的细节内容。setState() 并非同步操作，也无任何有意义的返回结果，仅仅是简单地描述其函数签名而没有深入地探讨其各种影响和表现，这对初学者是极不友好的。

初学者必须花上大量时间去找出问题：Google 上搜、StackOverflow 上搜、GitHub issues 里搜。

setState() 为何如此严苛？

setState() 的怪异表现并非 bug，而是特性。实际上，甚至可以说这是 React 之所以存在的根本原因。

React 的一大创作动机就是保证确定性渲染：给定应用 state，渲染出特定结果。理想情况下，给定 state 相同，渲染结果也应相同。

为了达到此目的，当发生变化时，React 通过采取一些限制性手段来管理变化。我们不能随意取得某些 DOM 节点然后就地修改之。相反，React 负责 DOM 渲染；当 state 发生改变时，也由 React 决定如何重绘。我们不渲染 DOM，而是由 React 来负责。

为了避免在 state 更新的过程中触发重绘，React 引入了一条规则：

React 用于渲染的 state 不能在 DOM 渲染的过程中发生改变。我们不能决定组件 state 何时得到更新，而是由 React 来决定。

困惑就此而来。当你调用 setState() 时，你以为你设置了 state，其实并没有。

“你就接着装逼，你以为你所以为的就是你所以为的吗？”

何时使用 setState()？

我一般只在不需要持久化 state 的自包含功能单元中使用 setState()，例如可复用的表单校验组件、自定义的日期或时间选择部件（widget）、可自定义界面的数据可视化部件等。

我称这种组件为“小部件（widget）”，它们一般由两个或两个以上组件构成：一个负责内部 state 管理的容器组件，一个或多个负责界面显示的子组件

几条立见分晓的检验方法（litmus tests）：

是否有其他组件是否依赖于该 state？
是否需要持久化 state？（存储于 local storage 或服务器）

如果这两个问题的答案都是“否”的话，那使用 setState() 基本是没问题的；否则，就要另作考虑了。

据我所知，Facebook 使用受管于 Relay container 的 setState() 来包装 Facebook UI 的各个不同部分，例如大型 Facebook 应用内部的迷你型应用。于 Facebook 而言，以这种方式将复杂的数据依赖和需要实际使用这些数据的组件放在一起是很好的。

对于大型（企业级）应用，我也推荐这种策略。如果你的应用代码量非常大（十万行以上），那此策略可能是很好的 —— 但这并不意味着这种方式就不能应用于小型应用中。

类似地，并不意味着你不能将大型应用拆分成多个独立的迷你型应用。我自己就结合 Redux 为企业级应用这样做过。例如，我经常将分析面板、消息管理、系统管理、团队/成员角色管理以及账单管理等模块拆分成多个独立的应用，每个应用都有其自己的 Redux store。通过 API tokens 和 OAuth，这些应用共享同一个域下的登录/session 管理，感觉就像是一个统一的应用。

对于大多数应用，我建议默认使用 Redux。需要指出的是，Dan Abramov（Redux 的作者）在这一点上和我持相反的观点。他喜欢应用尽可能地保持简单，这当然没错。传统社区有句格言如是说：“除非真得感到痛苦，否则就别用 Redux”。

而我的观点是：

“不知道自己正走在黑暗中的人是永远不会去搜寻光明的“。

正如我说过的，在某些情况下，Redux 比 setState() 更简单。通过消除一切和共享的可变 state 以及同步依赖有关的 bug，Redux 简化了 state 管理问题。

setState() 肯定要学，但即使你不想使用 Redux，你也应该学学 Redux。无论你采用何种解决方案，它都能让你从新的角度思考去应用的 state 管理问题，也可能能帮你简化应用 state。

对于有大量衍生（derived）state 的应用而言， MobX 可能会比 setState() 和 Redux 都要好，因为它非常擅于高效地管理和组织需要通过计算得到的（calculated）state。

得利于其细粒度的、可观察的订阅模型，MobX 也很擅于高效渲染大量（数以万计）动态 DOM 节点。因此，如果你正在开发的是一款图形游戏，或者是一个监控所有企业级微服务实例的控制台，那 MobX 可能是个很好的选择，它非常有利于实时地可视化展示这种复杂的信息。

接下来

想要全面学习如何用 React 和 Redux 开发软件？

跟着 Eric Elliott 学 Javacript，机不可失时不再来！

Eric Elliott 是 “编写 JavaScript 应用” （O’Reilly）以及 “跟着 Eric Elliott 学 Javascript” 两书的作者。他为许多公司和组织作过贡献，例如 Adobe Systems、Zumba Fitness、The Wall Street Journal、ESPN和BBC等 , 也是很多机构的顶级艺术家，包括但不限于 Usher , Frank Ocean , Metallica。

大多数时间，他都在 San Francisco Bay Area，同这世上最美的女子在一起（译注：这是怕老婆呢还是怕老婆呢还是怕老婆呢？）。

《优雅的 Ruby》40 页抢鲜试读

qinfanpeng — Tue, 28 Mar 2017 09:19:29 +0800

百度度云盘地址

《Ruby 元编程》《Ruby 原理剖析》的姊妹篇《优雅的 Ruby》上天猫了

qinfanpeng — Mon, 27 Mar 2017 09:30:04 +0800

多年以来，一直觉得 Rubyist 的 Sense 都比较高，但我们其实可以做得更好。估计坛子里大部分小伙伴对《Ruby 元编程》、《Ruby 原理剖析》都比较熟悉，如果还知道《重构》、《重构 Ruby 版》的话，基本可以断定为老司机了。相信作为这些前辈的姊妹篇，《优雅的 Ruby》定不会让你失望的。

天猫地址：https://detail.tmall.com/item.htm?spm=0.0.0.0.7rCHQM&id=547256521153 | 京东地址：https://item.jd.com/12164444.html | 豆瓣地址：https://book.douban.com/subject/26990698/

Ruby 就是为了让程序员快乐编程而生的。 —— 松本行弘（Matz）

若只如初见

你可能和我一样，第一次见识到 Ruby 的强大时很兴奋。对我而言，正是下面这样的代码，让我对 Ruby 一见倾心。

3.times do
  puts "Hello, Ruby world!"
end

时至今日，在我所知道的编程语言中，这仍是表达“重复三次”最简洁、最直接的方式。更何况，在使用过一些所谓的面向对象语言之后，我发现只有 Ruby 真正做到了一切皆对象，甚至数字 3 都是对象。这简直让我欣喜若狂！

遭遇现实

Ruby 几乎实现了程序员梦寐以求的愿望：用伪代码编程。它以一种简短、清晰、一目了然的方式编程。没有冗长乏味的模板，没有杂乱的语法，有的只是用最小的代价把业务逻辑转换为程序逻辑。

但是随着 Ruby 程序的规模增长，一切开始变味了。现实的丑陋开始显现，代码里充斥着各种异常处理和边界检查。就这样一点点的，代码开始失去原有的美感。代码里开始布满复杂的 if/then/else 嵌套逻辑和&&条件。对象不再像是接受消息的实体，而是变得像属性的收容所。一旦业务逻辑和异常处理共处，begin/rescue/end 这样的代码结构就会毫不犹豫地开始滋生。测试代码也变得越来越令人费解。最初的兴奋不复存在了。

重拾快乐

本书希望帮助读者重拾初学 Ruby 的那份快乐，像写故事一样写代码，找回写代码写到不经意微笑的状态，养成快乐编程的习惯。这些收获可以让你为获得更大的快乐而尝试更大的项目，这种快乐就如同初识 Ruby 时的兴奋一样。

Redux Actions & Redux Thunk

qinfanpeng — Sun, 15 Jan 2017 17:48:43 +0800

原文地址： http://qinfanpeng.github.io/jekyll/update/2017/01/03/redux_actions_and_redux_thunk.html

[slide]

Agenda

FSA
Action Creator
redux-actions
redux-promise
redux-thunk

[slide]

Agenda

FSA
Action Creator
redux-actions
redux-promise
redux-thunk

[slide]

Rails REST Routes

HTTP Verb	Path	Controller#Action	Used for
GET	/todos	todos#index	display a list of all todos
GET	/todos/new	todos#new	return an HTML form for creating a new todo
POST	/todos	todos#create	create a new todo
GET	/todos/:id	todos#show	display a specific todo
GET	/todos/:id/edit	todos#edit	return an HTML form for editing a todo
PATCH/PUT	/todos/:id	todos#update	update a specific todo
DELETE	/todos/:id	todos#destroy	delete a specific todo

[note] Restul 中由 Http Verb 和 Path 共同决定“要做什么” [/note]

[slide]

Rails Controller & Actions

class TodosController < ApplicationController
  # GET /todos
  def index
    @todos = Todo.all
  end

  # GET /todos/:id
  def show
    @todo = Todo.find(params[:id])
  end

  # GET /todos/new
  def new
    @todo = Todo.new
  end

  # POST /todos
  def create
    @todo = Todo.new(params[:todo])

    if @todo.save
      redirect_to @todo
    else
      render 'new'
    end  
  end

  # ...
end

[note] Controller 中的 Action 可以从 params 中获取 http 参数。结合起来看，Flux 中的 Action 要做的事情也极其类似：

决定“要做什么”
携带必要的参数 [/note]

[slide]

Describe Redux Action in One Sentence

What to do ? {:&.fadeIn}
And along with necessary data

[slide]

FSA(Flux Standard Action)

{
  type: ADD_TODO,
  payload: {
    text: 'Do something.'  
  }
}

{
  type: ADD_TODO,
  payload: new Error(),
  error: true
}

[slide]

Flux Standard Action Specifications

An action MUST {:&.fadeIn}
- be a plain JavaScript object. {:&.fadeIn}
- have a type property.
An action MAY have:
- an error property. {:&.fadeIn}
- a payload property.
- a meta property.
An action MUST NOT include properties other than type, payload, error, and meta.

[slide]

Benefit of using FSA

Standard to Follow {:&.fadeIn}
Easy to switch Flux implementations
More friendly to middleware

[slide]

Use Action Literal Directly

{:&.fadeIn}

store.dispatch({
  type: ADD_TODO,
  payload: {
    text: 'Do one thing.'  
  }
})

store.dispatch({
  type: ADD_TODO,
  payload: {
    text: 'Do another thing.'  
  }
})

[note] 直接使用 Action 字面量虽然直接，但繁琐、重复、极像样板（Boilerplate）、代码将代码的主要目的淹没在了细节中（暴露了不必要的细节） [/note]

[slide]

Encapsulate Action in Action Creator

{:&.fadeIn}

const addTodo = (text) => {
  return {
    type: ADD_TODO,
    payload: { text }
  }  
}

store.dispatch(addTodo('Do one thing.'))
store.dispatch(addTodo('Do another thing.'))

[note] 利用 Action Creator 封装了细节，减少重复，且令调用代码的意图一目了然。 [/note]

[slide]

Todo Actions (by Action Creators)

{:&.fadeIn}

const addTodo = (text) => {
  return {
    type: ADD_TODO,
    payload: { id: uuid.v4(), text }
  }
}

const updateTodo = (id, text) => {
  return {
    type: UPDATE_TODO,
    payload: { id, text }
  }
}

const clearTodos = () => {
  return {type: CLEAR_TODOS}
}

[note] 即使采用了 Action Creator，但还是有重复的影子，不够完美。 [/note]

[slide]

Use redux-actions to Simplify Action Creator

{:&.fadeIn}

// Solution One, which is perfer
const addTodo = (text) => {
  return createAction(ADD_TODO)({ id: uuid.v4(), text })
}
store.dispatch(addTodo(1, 'Do something'))

// Solution Two
const addTodo = createAction(ADD_TODO)
store.dispatch(addTodo({id: uuid.v4(), text: 'Do something'}))

const updateTodo = (id, text) => {
  return createAction(UPDATE_TODO)({ id, text })
}

const clearTodos = createAction(CLEAR_TODOS_TODO)
store.dispatch(clearTodos())

[note] 借助 redux-actions 的 createAction 进一步消除重复，简化代码。 [/note]

[slide]

Common Misuse of redux-actions

{:&.fadeIn}

const deleteTodo = (id) => {
  return createAction(DELETE_TODO)(id)
}

// Same as
const deleteTodo = (id) => {
  return {
    type: DELETE_TODO,
    payload: id
  }
}

const todos = handleActions({
  [DELETE_TODO]: (state, { payload }) => {
    // What the hell is payload ?
    return deleteTodo(state, payload)
  },
}, [])

[note] payload 中的数据应该有自己的结构，而非直接塞给 payload，否则的话，reducer 里代码根本不知道 payload 里有啥。 [/note]

[slide]

the Way to use redux-actions

{:&.fadeIn}

const deleteTodo = (id) => {
  return createAction('DELETE_TODO')({ id })
}

const todos = handleActions({
  DELETE_TODO: (state, { payload }) => {
    return deleteTodo(state, payload.id)
  },
}, [])

[slide]

use redux-promise to Call API

const fetchTodo = (id) => {
  return {
    type: 'FETCH_TODO',
    payload: fetch(`/todos/${id}`)
  }
}

// Or 
const fetchTodo = (id) => {
  return fetch(`/todos/${id}`)
           .then(todo => {
               return {
               type: 'FETCH_TODO',
               payload: todo
             }         
           })
}

store.dispatch(fetchTodo(1))

[note] redux-promise 这个 middleweare 可以识别 payload 为 promise 的 action 或全由 promise 组成的整个 action。 [/note]

[slide]

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

use redux-thunk to Call API

const fetchTodo = (id) => {
  return (dispatch, getState) => {
    fetch(`/todos/${id}`)
      .then(todo => {
        dispatch(createAction(FETCH_TODO)({ todo }))
      })
      .catch(error => {
        dispatch(createAction(FETCH_TODO)(error))
      })
  }
}

store.dispatch(fetchTodo(1))

[note] redux-thunk 也可处理 promise。 [/note]

=====

use redux-thunk to Conditional Dispatch

const addTodo = (text) => {
  return (dispatch, getState) => {
    if (getState().todos.length <= 3) {
        dispatch(createAction(FETCH_TODO)({ todo }))
    }
  }
}

[note] redux-thunk 还可用于按需调用。 [/note]

=====

Use redux-thunk to Dispatch Multiple Actions at Once

const fetchTodo = (id) => {
  return (dispatch, getState) => {
    dispatch(createAction(START_FETCH_TODO)({ todo }))

    fetch(`/todos/${id}`)
      .then(todo => {
        dispatch(createAction(FETCH_TODO_SUCCESS)({ todo }))
        // dispatch(createAction(TODO_RECIVED)({ todo }))
      })
      .catch(error => {
        dispatch(createAction(FETCH_TODO_FAIL)(error))
      })
  }
}

[note] redux-thunk 还可用于批量调用多个 action。显然 redux-thunk 的适用场景要比 redux-promise 要广。 [/note]

[/magic]

[slide]

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

Overuse redux-thunk

const updateTodo = (id, text) => {
  return (dispatch) => {
     return dispatch(createAction(UPDATE_TODO)({ id, text }))
  }
}

[note] 并非所有的 action 都要写成 thunk 形式。 [/note]

====

Overuse redux-thunk

const mapStateToProps = (state, ownProps) => ({})
const mapDispatchToProps = (dispatch, ownProps) => ({
  updateTodo: (id, text) => {
    return (dispatch) => {
      return dispatch(createAction(UPDATE_TODO)({ id, text }))
    }
  },
  addTodo: (text) => {
    return (dispatch) => {
      return dispatch(createAction(ADD_TODO)({ id: uuid.v4(), text }))
    }
  },
  toggleTodo: (id) => {
    return (dispatch) => {
      return dispatch(createAction(TOGGLE_TODO)({ id: uuid.v4(), text }))
    }  
  },                
})

@connect(mapStateToProps, mapDispatchToProps)

[note] 把上面的方法 inline 后，就显得更碍眼了。 [/note]

====

Overuse reason ?

Not familiar with bindActionCreators
Suppose will take over everything
Copy & paste

====

react-redux will auto use `bindActionCreators`

const mapStateToProps = (state, ownProps) => ({})
const mapDispatchToProps = (dispatch, ownProps) => ({
  updateTodo: (id, text) => {
    return (dispatch) => {
      return dispatch(createAction(UPDATE_TODO)({ id, text }))
    }
  },
  addTodo: (text) => {
    return (dispatch) => {
      return dispatch(createAction(ADD_TODO)({ id: uuid.v4(), text }))
    }
  },
  toggleTodo: (id) => {
    return (dispatch) => {
      return dispatch(createAction(TOGGLE_TODO)({ id: uuid.v4(), text }))
    }  
  },                
})

const mapStateToProps = (state, ownProps) => ({})
const mapDispatchToProps = {
  updateTodo: (id, text) => createAction(UPDATE_TODO)({ id, text }),
  addTodo: (text) => createAction(ADD_TODO)({ id: uuid.v4(), text }),
  toggleTodo: (id) => createAction(TOGGLE_TODO)({ id: uuid.v4(), text }),                
}

// will auto call bindActionCreators(mapDispatchToProps, dispatch)

@connect(mapStateToProps, mapDispatchToProps)

====

redux-thunk Source Code

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

====

Fix The Overuse of redux-thunk

const updateTodo = (id, text) => {
  return (dispatch) => {
     return createAction('UPDATE_TODO')({ id, text })
  }
}

const updateTodo = (id, text) => createAction('UPDATE_TODO')({ id, text })

[/magic]

[slide]

Thank You & QA

以前端工程师的视角看代码质量

qinfanpeng — Fri, 06 Jan 2017 17:40:40 +0800

https://github.com/ryanmcdermott/clean-code-javascript

常见重构手法 (下)

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

Property Based Testing --- 懒程序员也能写出 1000 的测试

qinfanpeng — Thu, 22 Dec 2016 21:46:29 +0800

http://www.slideshare.net/ScottWlaschin/an-introduction-to-property-based-testing

常见重构手法 (上)

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

转让一张 RubyConf 的门票

qinfanpeng — Thu, 22 Sep 2016 14:17:31 +0800

我因临时家里有事，所以参加不了明天开始的 Ruby Conf，故打算转让门票。价钱都好商量。

联系方式：

微信：qinfanpeng
邮箱：qinfanpeng@qq.com
Q Q: 644458812
电话：138 8073 4982

探秘模块混入 (include Module) 背后的故事

qinfanpeng — Mon, 27 Jun 2016 18:36:18 +0800

原文地址：http://qinfanpeng.github.io/jekyll/update/2016/06/24/the_secret_of_module_include.html 对应视频版：http://v.youku.com/v_show/id_XMTYyMzAyOTY5Mg==.html

先上段代码：

class Person
  def wear
    '穿衣'
  end
end

class Economist < Person
end

economist = Economist.new
economist.wear # => ? ①

module Professor
  def wear
    "戴眼镜"
  end
end

class Economist < Person
  include Professor
end

economist.wear # => ？②

module Professor
  def wear
    "#{super}，戴眼镜"
  end
end

economist.wear # => ？③

module Expert
  def refute_rumor
    '辟谣'
  end
end

module Professor
  include Expert
end

economist.refute_rumor # => ？④

Economist.include Professor
economist.refute_rumor # => ？⑤

相信对于上面四处问号，我们都有自己的答案了。毫无疑问①处会返回“穿衣”，这里我们都不会错；②是返回“穿衣”还是“戴眼镜”呢？估计要是没有③处的对比的话，估计有人会回答错误，②的正确答案是“戴眼镜”；那么③的正确答案自然是“穿衣，戴眼镜”了；④处会返回“辟谣”吗？，并不会，这里会报错：No Method Error；⑤会正确返回“辟谣”

不过前面答对与否，我们最好理解背后的原理，尤其是④处的情况。①处最好理解，调用了继承自Person的wear方法而已，继承体系大致如下：

下面来看②③两处处，由前面的答案可知②调用的是来自Professormodule 中的wear方法，而非PersonClass 中的。结合②③两处，可大致得出如下继承体系：

等等，如果是这样的话，那么Professor被另一个 class include 的时候，该怎么办呢？总不能说一个 module 有多个 super 吧。记得以前看《Ruby 元编程》的时候，里面有很多类似的图。为了节约时间就不去翻书了，直接去 Google Image 里搜索关键字：ruby include，不难发现这张图：

“被 include 的实际是 module 的副本，而非 module 本身”，如此一来 module 被 include 无论多少次都无所谓了，因为更改的是那些对应副本的super。所以前面的图应该改成这样才对：

再看下③处，这里我们是在Professor被 include 后（实际上被 include 的是的Professor的副本），用类似打开类的方式修改的Professor，并没有修改其副本。这里正确返回“穿衣，戴眼镜”，能说明Professor和它的副本共享了同一份方法实现，即是说拷贝的时候并没拷贝底层的方法，类似下面这样：

与③不同是④是通过在Professorinclude 另外一个 moduleExpert来修改的，而这个过程又发生在Professor被 include 之后。这种情况下Economist感知不到Professor的改变。究其深层原因，结合前面的经验，不难得出以下结果：

我们索性一鼓作气画一下⑤处的情况：

小结

任何时候 include module 都 include 的是对应的副本，而非 module 本身。这是由于 include 会改变继承体系，如果直接 include module 本身的话，就使得该 module 难以再被其他地方 include 了，而每次都 include module 的副本则不会有这样的问题。
module 和它被 include 的副本共享同一份方法实现，因而直接修改方法，会反映到已经 include 的地方去。
通 include 另一个 module B 的方式修改一个已经被 include 了的 module A，不会体现到 include A 的地方，因为 B 并没有被 include A 的副本中去。

参考资料

《Ruby Under a Microscope》（对应中文版《Ruby 原理剖析》由张汉东先生翻译，应该不久就可以和大家见面了。如果说《Ruby 元编程》让我们了解很多 Ruby 高级用法的话，那么《Ruby 原理剖析》则在更深层次上系统地阐述了这些高级用法背后的原理）
《Ruby 元编程（第 2 版）》

Mongoid inverse_of not work as well as active_records

qinfanpeng — Tue, 14 Jun 2016 09:14:41 +0800

原文地址：Mongoid inverse_of not work as well as active_records

Rails 4.1 以后，大多数情况下它都能自动帮我们加上inverse_of。大概也是由于这个原因，现在我们少有提到inverse_of了，但是某些情况下 Rails 不会自动帮我们加的，需要我们自己留意：

# activerecord-4.2.5.1/lib/active_record/reflection.rb:553
VALID_AUTOMATIC_INVERSE_MACROS = [:has_many, :has_one, :belongs_to]
INVALID_AUTOMATIC_INVERSE_OPTIONS = [:conditions, :through, :polymorphic, :foreign_key]

def can_find_inverse_of_automatically?(reflection)
  reflection.options[:inverse_of] != false &&
    VALID_AUTOMATIC_INVERSE_MACROS.include?(reflection.macro) &&
    !INVALID_AUTOMATIC_INVERSE_OPTIONS.any? { |opt| reflection.options[opt] } &&
    !reflection.scope
end

下面先来温习一下inverse_of相关作用。

Memory Optimization Associated Object

class Dungeon < ActiveRecord::Base
  has_many :traps
end

class Trap < ActiveRecord::Base
  belongs_to :dungeon, foreign_key: :my_dungeon_id
end

这里之所以要加上foreign_key: :my_dungeon_id是为了阻止 Rails自动帮我们加上inverse_of。

dungeon = Dungeon.first
trap = dungeon.traps.first

trap.dungeon # 此处还会去查询数据库（有点不合理，对吧）

trap.dungeon == dungeon     # => true
trap.dungeon.equal? dungeon # => false（说明它俩虽然内容相同，但在内存中却不是同一个对象）

dungeon.level == trap.dungeon.level # => true
dungeon.level = 10
dungeon.level == trap.dungeon.level # => false（也有点不合理，对吧）

下面我们移除foreign_key: :my_dungeon_id，如此一来 Rails便会自动帮我们加上inverse_of的：

class Trap < ActiveRecord::Base
  belongs_to :dungeon
end    

dungeon = Dungeon.first
trap = dungeon.traps.first

trap.dungeon # 此处不会再去查询数据库了

trap.dungeon == dungeon     # => true
trap.dungeon.equal? dungeon # => true（这才合情理嘛）

dungeon.level == trap.dungeon.level # => true
dungeon.level = 10
dungeon.level == trap.dungeon.level # => true

Creating associated objects across a has_many :through

class Post < ActiveRecord::Base 
  has_many :taggings 
  has_many :tags, :through => :taggings 
end

class Tag < ActiveRecord::Base 
  has_many :taggings 
  has_many :posts, :through => :taggings 
end

class Tagging < ActiveRecord::Base 
  belongs_to :tag, foreign_key: :my_tag_id
  belongs_to :post
end

同样加foreign_key: :my_tag_id是为了避免 Rails 自动帮我们加上inverse_of。

post = Post.first
tag = post.tags.build name: "ruby"
tag.save

tag.taggings # => []
tag.posts    # => []

造成最后两行返回空的本质原因是没保存对应的关联的数据tagging。现在如果移除foreign_key: :my_tag_id，就相当于加上了inverse_of: :taggings（Rails 自动加的）变成了下面这样：

class Tagging < ActiveRecord::Base 
  belongs_to :tag, inverse_of: :taggings
  belongs_to :post, inverse_of: :taggings
end

post = Post.first
tag = post.tags.build name: 'ruby'
tag.save

tag.taggings # => [... ]
tag.posts    # => [post]

说明 Rails 在保存关联数据时，需要知道反向的关联关系。

Automatically assign associated object

class Dungeon < ActiveRecord::Base
  has_many :traps
end

class Trap < ActiveRecord::Base
  belongs_to :dungeon, foreign_key: :my_dungeon_id

  validates_presence_of :dungeon
end

dungeon = Dungeon.new
trap = dungeon.traps.build

trap.valid?  # => false 这是因为 trap.dungeon 是nil。

# 加上inverse_of

class Trap < ActiveRecord::Base
  belongs_to :dungeon # 此时会自动加上 inverse_of: :dungeon
  validates_presence_of :dungeon
end

trap.valid?  # => false

Inverse_of in mongoid

初步看起来mongoid中的inverse_of只是起到自定义关联名称的作用，并不具备上面提到的那些功效：

class Lush
  include Mongoid::Document
  has_many :whiskeys, class_name: "Drink", inverse_of: :alcoholic
end

class Drink
  include Mongoid::Document
  belongs_to :alcoholic, class_name: 'Lush', inverse_of: :whiskeys
end

alcoholic = Lush.first
whiskey = alcoholic.whiskeys.first

whiskey.alcoholic == alcoholic     # => true
whiskey.alcoholic.equal? alcoholic # => false（对此貌似没有好的方式可以解决）

# 会导致 N+1 问题
alcoholic.whiskeys.each { |whiskey| whiskey.some_method_which_use_alcoholic }

# 不太优雅的解决方案一（会再查一次alcoholic，但不会有N+1）
alcoholic.whiskeys.includes(:alcoholic).each { |whiskey| whiskey.some_method_which_use_alcoholic }

# 不太优雅的解决方案二（不会再查询alcoholic）
alcoholic.whiskeys.each do |whiskey|
  whiskey.alcoholic = alcoholic
  whiskey.some_method_which_use_alcoholic 
end

参考资料

activerecord-4.2.5.1/lib/active_record/associations.rb
Exploring the inverse of option on rails model associations

一次利用 byebug 和 RubyMine 刨根问底的过程

qinfanpeng — Thu, 19 May 2016 14:40:19 +0800

一次利用 byebug 和 RubyMine 刨根问底的过程

先看个现象：

class User
  include Mongoid::Document
  has_many :orders
end
class Order
  include Mongoid::Document
  belongs_to :user
end

user.orders.pluck :id         # 正常返回id
user.orders.try :pluck, :id   # 返回 nil

奇怪的是第二行居然返回nil。user.orders.try :pluck, :id返回nil大致有以下三种可能：

user.orders返回nil，不过由于user.orders.pluck :id可以正常返回 id，排除这种可能；
orders.pluck :id 返回 nil，同上，也可排除这种可能；
user.orders.try :pluck, :id中的user.orders上没有pluck方法。这看起来是最不可能的情况，但是...

为了弄清原因，再来做个试验：

user.orders.try! :pluck, :id  # NoMethodError: undefined method `pluck' for #<Array:0x0...>

这次我们用的是try!而非try，其结果正好符合上面的第 3 中情况。唯有这样假设方能解释得通：user.orders.pluck :id中的user.orders返回的是Mongoid::Criteria；而user.orders.try :pluck, :id中的user.orders返回的是Array。下面我们来借助byebug和RubyMine看看是否如此：

光标 hover 至一处调用pluck的地方，Go to Declaration（⌘B），搜索找到mongoid中的定义gems/mongoid-5.0.1/lib/mongoid/contextual/mongo.rb:399，加上byebug:

def pluck(*fields)
  byebug
  normalized_select = fields.inject({}) do |hash, f|
    hash[klass.database_field_name(f)] = 1
    hash
  end

  view.projection(normalized_select).reduce([]) do |plucked, doc|
    values = normalized_select.keys.map do |n|
      n =~ /\./ ? doc[n.partition('.')[0]] : doc[n]
    end
    plucked << (values.size == 1 ? values.first : values)
  end
end

打开 Rails Console，运行user.orders.pluck :id，然后运行backtrace:
定位到gems/mongoid-5.0.1/lib/mongoid/relations/referenced/many.rb:414 :

def method_missing(name, *args, &block)
  byebug
  if target.respond_to?(name)
    target.send(name, *args, &block)
  else
    klass.send(:with_scope, criteria) do
      criteria.public_send(name, *args, &block)
    end
  end
end

再次借助byebug不难发现这里的target已经是orders数组了，其 class 为Mongoid::Relations::Targets::Enumerable。由这里的代码得知：对于 target 支持的方法，直接在 target 上调用；target 不支持的方法则在criteria调用。拿我们前面的例子来说： user.orders.pluck :id中的 targetorders（Array）不支持pluck方法，所以其实是在user.orders返回的criteria上调用的pluck；而user.orders.try :pluck, :id，中的 targetuser.orders（Array）支持try方法，所以直接在 targetuser.orders上调用了，又因Array上没有pluck，故而返回 nil。

所以这样？

user.orders.try :map, &:id

Mongoid Paging and Iterating Over Large Collections

qinfanpeng — Mon, 09 May 2016 11:48:25 +0800

Mongoid Paging and Iterating Over Large Collections

遍历数据库中的所有记录时，我们首先想到的是Model.all.each。但是，当数据量很大的时候（数万？），这就不怎么合适了，因为Model.all.each会一次性加载所有记录，并将其实例化成 Model 对象，这显然会增加内存负担，甚至耗尽内存。

对于ActiveRecord 而言，有个find_each专门解决此类问题。find_each底层依赖于find_in_batches，会分批加载记录，默认每批为 1000。

对Mongoid而言，话说可以直接用Person.all.each，它会自动利用游标（cursor）帮你分批加载的。不过有个问题得留意一下：cursor有个 10 分钟超时限制。这就意味着遍历时长超过 10 分钟就危险了，很可能在中途遭遇no cursor错误。

# gems/mongo-2.2.4/lib/mongo/collection.rb:218
# @option options [ true, false ] :no_cursor_timeout The server normally times out idle cursors 
# after an inactivity period (10 minutes) to prevent excess memory use. Set this option to prevent that.

虽然可以这样来绕过它 Model.all.no_timeout.each，不过不建议这样做。另外默认的batch_size不一定合适你，可以这样指定Model.all.no_timeout.batch_size(500).each。不过 mongodb 的默认batch_size看起来比较复杂，得谨慎。（The MongoDB server returns the query results in batches. Batch size will not exceed the maximum BSON document size. For most queries, the first batch returns 101 documents or just enough documents to exceed 1 megabyte. Subsequent batch size is 4 megabytes. To override the default size of the batch, see batchSize() and limit().

For queries that include a sort operation without an index, the server must load all the documents in memory to perform the sort before returning any results.

As you iterate through the cursor and reach the end of the returned batch, if there are more results, cursor.next() will perform a getmore operation to retrieve the next batch. )

Model.all.each { print '.' } 将得到类似的查询：

类似的方案应是利用skip和limit，类似于这样Model.all.skip(m).limit(n)。很不幸的是，数据量过大时，这并不好使，因为随着 skip 值变大，会越来越慢（The cursor.skip() method is often expensive because it requires the server to walk from the beginning of the collection or index to get the offset or skip position before beginning to return results. As the offset (e.g. pageNumber above) increases, cursor.skip() will become slower and more CPU intensive. With larger collections, cursor.skip() may become IO bound.）。这让我想起了曾经看过的帖子will_paginate 分页过多 (大概 10000 页)，点击最后几页的时候，速度明显变慢，大致原因就是分页底层用到了offset，也是因为 offset 越大查询就会越慢。

让我们再次回到ActiveRecord的find_each上来。Rails 考虑得很周全，它底层没利用offset，而是将每批查询的最后一条记录的id作为下批查询的primary_key_offset：

# gems/activerecord-4.2.5.1/lib/active_record/relation/batches.rb:98
def find_in_batches(options = {})
  options.assert_valid_keys(:start, :batch_size)

  relation = self
  start = options[:start]
  batch_size = options[:batch_size] || 1000

  unless block_given?
    return to_enum(:find_in_batches, options) do
      total = start ? where(table[primary_key].gteq(start)).size : size
      (total - 1).div(batch_size) + 1
    end
  end

  if logger && (arel.orders.present? || arel.taken.present?)
    logger.warn("Scoped order and limit are ignored, it's forced to be batch order and batch size")
  end

  relation = relation.reorder(batch_order).limit(batch_size)
  records = start ? relation.where(table[primary_key].gteq(start)).to_a : relation.to_a

  while records.any?
    records_size = records.size
    primary_key_offset = records.last.id
    raise "Primary key not included in the custom select clause" unless primary_key_offset

    yield records

    break if records_size < batch_size

    records = relation.where(table[primary_key].gt(primary_key_offset)).to_a
  end
end

前面的Model.all.no_timeout.batch_size(1000).each是 server 端的批量查询，我们也可模仿出 client 端的批量查询，即Mongoid版的find_each:

# /config/initializers/mongoid_batches.rb
module Mongoid
  module Batches
    def find_each(batch_size = 1000)
      return to_enum(:find_each, batch_size) unless block_given?

      find_in_batches(batch_size) do |documents|
        documents.each { |document| yield document }
      end
    end

    def find_in_batches(batch_size = 1000)
      return to_enum(:find_in_batches, batch_size) unless block_given?

      documents = self.limit(batch_size).asc(:id).to_a
      while documents.any?
        documents_size = documents.size
        primary_key_offset = documents.last.id

        yield documents

        break if documents_size < batch_size
        documents = self.gt(id: primary_key_offset).limit(batch_size).asc(:id).to_a
      end
    end
  end
end

Mongoid::Criteria.include Mongoid::Batches

最后对于耗时操作，还可考虑引入并行计算，类似于这样：

Model.find_each { ... }

Model.find_in_batches do |items|
  Parallel.each items, in_processes: 4 do |item|
    # ...
  end
end

参考链接

Ruby China 看不了贴了

qinfanpeng — Wed, 03 Feb 2016 14:35:11 +0800

Rails & Ruby Best Practice

qinfanpeng — Tue, 26 Jan 2016 11:23:55 +0800

其中部分示例稍老，但其思想仍然适用

Setup

gem install rails_best_practices

rails_best_practices .

default_scope is Evil

class Post
  default_scope where(published: true).order("created_at desc")
end

you can't override default scope

Post.order("updated_at desc").limit(10) # =>
# Post Load (17.3ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`published` = 1 ORDER BY created_at desc, updated_at desc LIMIT 10

Post.unscoped.order("updated_at desc").limit(10) # =>
# Post Load (1.9ms)  SELECT `posts`.* FROM `posts` ORDER BY updated_at desc LIMIT 10

default_scope will affect your model initialization

Post.new # =>
<Post id: nil, published: true, title: nil, created_at: nil, updated_at: nil, user_id: nil>

Not Rescue Exception

loop do
  begin
    sleep 1
    eval "djsakru3924r9eiuorwju3498 += 5u84fior8u8t4ruyf8ihiure"
  rescue Exception => e
    puts "I refuse to fail or be stopped!"
  end
end

Ruby Exception Class Hierarchy

Exception
  NoMemoryError
  ScriptError
    LoadError
    NotImplementedError
    SyntaxError
  SignalException
    Interrupt
      Timeout::Error    # < ruby 1.9.2
  StandardError         # caught by rescue (default if no type was specified)
    ArgumentError
    IOError
      EOFError
    IndexError
    LocalJumpError
    NameError
      NoMethodError
    RangeError
      FloatDomainError
    RegexpError
    RuntimeError
      Timeout::Error    # >= ruby 1.9.2
    SecurityError
    SocketError
    SystemCallError
    SystemStackError
    ThreadError
    TypeError
    ZeroDivisionError
  SystemExit
  fatal

Rescue StandardError, Not Exception

begin
  # iceberg!
rescue => e
  # lifeboats
end

# which is equivalent to:
begin
  # iceberg!
rescue StandardError => e
  # lifeboats
end

Rescue Exception for Logging/Reporting

begin
  # iceberg?
rescue Exception => e
  # do some logging
  raise e  # not enough lifeboats ;)
end

Needless Deep Nesting

# config/routes.rb
resources :auctions do
  resources :bids do
    resources :comments 
  end
end

edit_auction_bid_comment_path(@auction, @bid, @comment)

As we already have the resource_id parameter in the URLs for #show, #edit, #update and #destroy
So only need to nest #index, #new and #create under the resource

Rewrite Deep Nesting

resources :auctions do
  resources :bids, only: [:index, :new, :create]
end

resources :bids, only: [:show, :edit, :update, :destroy]

resources :auctions, shallow: true do 
  resources :bids do
    resources :comments 
  end
end

resources :auctions do 
   resources :bids
end

resources :bids do 
  resources :comments
end

resources :comments

Shallow Routes

bid_comments GET    /bids/:bid_id/comments(.:format)
             POST   /bids/:bid_id/comments(.:format)
new_bid_comment GET /bids/:bid_id/comments/new(.:format)
   edit_comment GET /comments/:id/edit(.:format)
        comment GET /comments/:id(.:format)
             PATCH  /comments/:id(.:format)
             PUT    /comments/:id(.:format)
             DELETE /comments/:id(.:format)
auction_bids GET    /auctions/:auction_id/bids(.:format)
             POST   /auctions/:auction_id/bids(.:format)
new_auction_bid GET /auctions/:auction_id/bids/new(.:format)
       edit_bid GET /bids/:id/edit(.:format)
            bid GET /bids/:id(.:format)
             PATCH  /bids/:id(.:format)
             PUT    /bids/:id(.:format)
             DELETE /bids/:id(.:format)
    auctions GET    /auctions(.:format)
             POST   /auctions(.:format)
    new_auction GET /auctions/new(.:format)
   edit_auction GET /auctions/:id/edit(.:format)
        auction GET /auctions/:id(.:format)
     ...

Replace Instance Variable With Local Variable

Downside of using instance variables in partials

class PostsController < ApplicationController
  def show
    @item = ...
  end
end
# sidebar partial use @item directly
<%= render partial: "sidebar" %>

The downside of using instance variables in partials is that you create a dependency in the partial to something outside the partial's scope (coupling). This makes the partial harder to reuse, and can force changes in several parts of the application when you want to make a change in one part.

Partials that use instance variables in partial:

Discourage reuse, as they can only easily be reused in actions that set up instance variables with the same name and data
Shotgun Surgy, Must change when the instance variable in any controller that uses the partial changes either the instance variable name or its type or data structure, and vice versa.

Replace Instance Variable With Local Variable

###Instead, pass locals to the partials

<%= render 'reusable_partial', item: @item %>

the partial only references item and not @item.

<%= render 'reusable_partial', :item => @other_object.item %>

Also, this can be reused in contexts where there is no @item:

<%= render 'reusable_partial', :item => @duck %>

Now, because the partial only references item and not @item, the action that renders the view that renders the reusable_partial is free to change without affecting the reusable_partial and the other actions/views that render it:

If my @duck changes in the future and no longer quacks like reusable_partial expects it to (the object's interface changes), I can also use an adapter to pass in the kind of item that reusable_partial expects:

@duck changes in the future, I can also use an adapter.

<%= render 'reusable_partial', :item => itemlike_duck(@duck) %>

Use Scope Access

Check the permission by comparing the owner of object with current_user

class PostsController < ApplicationController
  def edit
    @post = Post.find(params[:id])
    if @post.user != current_user
      flash[:warning] = 'Access denied'
      redirect_to posts_url
    end
  end
end

Just use scope access to make permission check simpler.

class PostsController < ApplicationController
  def edit
    # raise RecordNotFound exception (404 error) if not found
    @post = current_user.posts.find(params[:id])
  end
end

The Law of Demeter

Code Smell

class Invoice < ActiveRecord::Base
  belongs_to :user
end

<%= @invoice.user.name %>
<%= @invoice.user.address %>
<%= @invoice.user.cellphone %>

Refactor

class Invoice < ActiveRecord::Base
  belongs_to :user
  delegate :name, :address, :cellphone, :to => :user, :prefix => true
end

<%= @invoice.user_name %>
<%= @invoice.user_address %>
<%= @invoice.user_cellphone %>

Keep Finders on Their Own Model

Bad Smell

class Post < ActiveRecord::Base
  has_many :comments

  def find_valid_comments
    self.comment.find(:all, :conditions => {:is_spam => false},
                            :limit => 10)
  end
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

class CommentsController < ApplicationController
  def index
    @comments = @post.find_valid_comments
  end
end

class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post

  scope :only_valid, -> { is_spam: false }
  scope :limit, lambda { |size| { :limit => size } }
end

class CommentsController < ApplicationController
  def index
    @comments = @post.comments.only_valid.limit(10)
  end
end

Use query attribute

Code Smell

<% if @user.login.blank? %>
  <%= link_to 'login', new_session_path %>
<% end %>

<% if @user.login.present? %>
  <%= @user.login %>
<% end %>

Refactor

<% unless @user.login? %>
  <%= link_to 'login', new_session_path %>
<% end %>

<% if @user.login? %>
  <%= @user.login %>
<% end %>

Simplify Render in Views

Before

<%= render :partial => 'sidebar' %>
<%= render :partial => 'shared/sidebar', :locals => { :parent => post } %>

After

<%= render 'sidebar' %>
<%= render 'shared/sidebar', :parent => post %>

if account && account.owner && account.owner.address
...
end

Isn't identical to

if account.try(:owner).try(:address)
...
end

Isn't identical to

if account&.owner&.address
...
end

There're similar when something is nil

account = Account.new(owner: nil) # account without an owner

account.owner.address
# => NoMethodError: undefined method `address' for nil:NilClass

account && account.owner && account.owner.address
# => nil

account.try(:owner).try(:address)
# => nil

account&.owner&.address
# => nil

&. operator only skips nil but recognizes false!

account = Account.new(owner: false)

account.owner.address
# => NoMethodError: undefined method `address' for false:FalseClass `

account && account.owner && account.owner.address
# => false

account.try(:owner).try(:address)
# => nil

account&.owner&.address
# => undefined method `address' for false:FalseClass`

When use `try`, whatch out misspelling!

account = Account.new(owner: Object.new)

account.owner.address
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>

account && account.owner && account.owner.address
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>`

account.try(:owner).try(:address)
# => nil

account&.owner&.address
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>`

There's a stricter version of try - try! for you:

account.try!(:owner).try!(:address)
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>`

References

判断 Rails partial 中变量是否定义的正确姿势

qinfanpeng — Wed, 09 Dec 2015 22:08:23 +0800

判断 Rails partial 中变量是否定义的正确姿势

假设最初我们引入了一个 Rails partial，内含feature-one:

# app/views/shared/_feature_partial.erb
# ...
<section class='feature-one'>
 This is the feature one
</section>
# ...

然后，很多地方都用到了这个 partial，类似于这样：

<%= render 'shared/feature_partial' %>
# 或这样
<%= render partial: 'shared/feature_partial' %>

突然有一天来了个新需求：也需要用到 feature_partial，但是不在需要其中的feature-one了。于是我们决定对feature_partial做如下改动：

# app/views/shared/_feature_partial.erb
# ...
<%- need_feature_one  = true unless defined? need_feature_one >
<%- if need_feature_one %>
   <section class='feature-one'>
     This is the feature one
   </section>
<%- end %>
# ...

首先，上面的need_feature_one = true unless defined? need_feature_one不能写成这样need_feature_one ||= true或这样need_feature_one = true unless need_feature_one，这应该无需多言。现在看起来完美了：对于feature_partial以前的引用无需做任何修改（修改最小化），功能便照样完好；对于新引用，若不需要feature-one，在引用的时候将need_feature_one设置为 false 即可，类似于下面这样：

<%= render 'shared/feature_partial', need_feature_one: false %>
# 或这样
<%= render partial: 'shared/feature_partial', locals: {need_feature_one: false} %>

若故事到此结束，那本文就完全没存在的必要了。事实证明，对于feature_partial以前的引用，need_feature_one = true unless defined? need_feature_one返回的永远都是nil，意外吧？要了解其中原委，还得从两方面说起：

通常而言，Ruby 中以问号结尾的方法都返回 true/false，如 (respond_to?、start_with？等)，然而defined?这货却并非如此，例证如下：

>> a = 1
 => 1
>> defined? a
 => "local-variable"
>> defined? b
 => nil
>> defined? nil
 => "nil"
>> defined? String
 => "constant"
>> defined? 1
 => "expression"
>> @c = 2 
>> defined? @c
 => "instance-variable"

看起来，defined?这货返回的是对应变量的类型，对于没定义的变量返回的是 nil。但这还是解释不了为啥need_feature_one = true unless defined? need_feature_one总返回nil阿。

若没提前定义need_feature_one，need_feature_one = true unless defined? need_feature_one永远返回nil，不妨假设：在进行defined? need_feature_one判断时，Ruby 已经为这种一行形式语法定义了名为need_feature_one的变量，默认值为nil；所以在进行defined? need_feature_one判断时因need_feature_one已经定义，所以need_feature_one = true一直没得到执行。下面来窥探一下其编译版本，验证一下我们的想法：

puts RubyVM::InstructionSequence.compile("need_feature_one = true unless defined? need_feature_one").disassemble
== disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>==========
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] need_feature_one
0000 trace            1                                               (   1)
0002 putnil                            
0003 putobject        "local-variable" # defined? need_feature_one 返回 "local-variable"，进一步说明此时 need_feature_one已定义
0005 swap
0006 pop
0007 branchunless     12               # 若defined?条件为false，则跳转至第12行
0009 putnil
0010 leave
0011 pop
0012 putobject        true             # 第12行在此
0014 dup
0015 setlocal_OP__WC__0 2
0017 leave
=> nil

抛开其他细节不谈，这里出现了“local-variable”，由前面对defined?的特性的了解可知，这是已定义本地变量的输出，说明在进行unless defined? need_feature_one判断时need_feature_one已定义，因而可以佐证我们的假设。关于 Ruby 编译、解析相关知识详见：Ruby 是如何解释运行程序的，欲知上面每条指令（YARV instruction）的意思，请期待《Ruby 原理剖析》。

下面再来看看其词法解析版本：

require 'ripper'
require 'pp'

pp Ripper.sexp("need_feature_one = true unless defined? need_feature_one")

[:program,
 # unless修饰符
 [[:unless_mod,
   # defined? 条件判断，注意这里的:var_ref，可认为是变量引用，大致可说明此时need_feature_one已经定义。
   [:defined, [:var_ref, [:@ident, "need_feature_one", [1, 40]]]],
   [:assign,
    [:var_field, [:@ident, "need_feature_one", [1, 0]]],
    # 将need_feature_one赋值为true。
    [:var_ref, [:@kw, "true", [1, 19]]]]]]]
=> [:program, [[:unless_mod, [:defined, [:var_ref, [:@ident, "need_feature_one", [1, 40]]]], [:assign, [:var_field, [:@ident, "need_feature_one", [1, 0]]], [:var_ref, [:@kw, "true", [1, 19]]]]]]]

留意上面第一个:var_ref，下面还会用作对比。

事实证明，下面这样是可以修复上面这个问题：

<%- unless defined? need_feature_one %>
 need_feature_one = true
<%- end %>

对应编译版本如下：

puts RubyVM::InstructionSequence.compile("unless defined? need_feature_one \n need_feature_one = true \n end").disassemble
== disasm: <RubyVM::InstructionSequence:<compiled>@<compiled>>==========
== catch table
| catch type: rescue st: 0003 ed: 0008 sp: 0000 cont: 0010
== disasm: <RubyVM::InstructionSequence:defined guard in <compiled>@<compiled>>
0000 putnil
0001 leave
|------------------------------------------------------------------------
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] need_feature_one
0000 trace            1                                               (   1)
0002 putnil
0003 putself
0004 defined          17, :need_feature_one, true
0008 swap
0009 pop
0010 branchunless     15
0012 putnil
0013 leave
0014 pop
0015 trace            1                                               (   2)
0017 putobject        true
0019 dup
0020 setlocal_OP__WC__0 2
0022 leave
=> nil

对比发现，这个编译版本不再有先前那样的“local-variable”了，说明在进行unless defined? need_feature_one判断时，need_feature_one尚未定义。

对应词法解析版本如下：

require 'ripper'
require 'pp'

pp Ripper.sexp("unless defined? need_feature_one \n need_feature_one = true \n end")

[:program,
 [[:unless,
   # defined?条件判断，注意此处是:vcall，而非先前的:var_ref，vcall代表Ruby还未识别出这里调用的need_feature_one是一个变量还是一个方法；而var_ref表明此时已经识别出是一个变量。大致可说明此时need_feature_one尚未定义。
   [:defined, [:vcall, [:@ident, "need_feature_one", [1, 16]]]],
   [[:assign,
     [:var_field, [:@ident, "need_feature_one", [2, 1]]],
     [:var_ref, [:@kw, "true", [2, 20]]]]],
   nil]]]
=> [:program, [[:unless, [:defined, [:vcall, [:@ident, "need_feature_one", [1, 16]]]], [[:assign, [:var_field, [:@ident, "need_feature_one", [2, 1]]], [:var_ref, [:@kw, "true", [2, 20]]]]], nil]]]

但 Ruby/Rails 如此优雅的存在，肯定有更优雅的解决方案。比如下面这样：

# 还行
need_feature_one = true unless local_assigns.has_key? :need_feature_one

# 好
need_feature_one = local_assigns.fetch(:need_feature_one, true)
# 或
need_feature_one = local_assigns.fetch(:need_feature_one) { true }

# 更好
# ... 等你来发现。

关于fetch两种用法的区别，可查阅《Confident Ruby》。

小结

看起来，带条件修饰符的变量赋值语句，Ruby 都会为其先赋值为 nil，然后进行条件判断，若条件满足，再进行第二次赋值操作。

参考资料

求 Markdown 工具推荐 (最好带批注 / 校对功能)

qinfanpeng — Sun, 06 Dec 2015 11:33:19 +0800

自己现在用 MacDown，是一款 Mou 的衍生开源产品，一切都好。只是每次校对的时候，还需要先弄到 word 里去，然后再发给朋友；最后再将校对应用于 markdown 里去。感觉很 low，不知大家有没有带批注/校对功能的 MarkDown 工具（在线版也行）推荐没？先拜谢！

Rails (3&4) 预加载 (preload) 的 3 种方式

qinfanpeng — Wed, 02 Dec 2015 09:35:36 +0800

Rails（3&4）预加载（preload）的 3 种方式

作者：Robert Pankowecki 原文地址：http://blog.arkency.com/2013/12/rails4-preloading/

本文是 2013 年的一篇老文章，资深人士请绕道。前些天自己遇到了些麻烦，详见：https://ruby-china.org/topics/28225 ，本来当初也看到过这篇文章，只因自己粗心，而没及时深读本文（毕竟对我而言英文没有中文那么直观），否则将节约我不少时间。翻译此文，希望能节约他人的几秒钟。

和 Rails 的 ActiveRecord 打交道，你大概已经习惯用#includes来预加载数据。但你知道为啥它生成的 SQL 有时小而美，有时却是个巨型查询，且每个表、列都被重命名过（"users"."id" AS t0_r0，"addresses"."id" AS t1_r0）？你知道##preload和#eager_load 也能帮你做这事儿吗？你知道 Rails4 中预加载方面有哪些变化吗？如果都不知道的话，请耐心读下去。本文不会太长，将助你了解预加载中哪些你不熟悉的方面。

首先让我们从 Active Record 关联关系（associations）定义开始，本文通篇将以此例为基础。

class User < ActiveRecord::Base
  has_many :addresses
end

class Address < ActiveRecord::Base
  belongs_to :user
end

下面是些实验数据，以便我们验证查询结果：

rob = User.create!(name: "Robert Pankowecki", email: "robert@example.org")
bob = User.create!(name: "Bob Doe", email: "bob@example.org")

rob.addresses.create!(country: "Poland", city: "Wrocław", postal_code: "55-555", street: "Rynek")
rob.addresses.create!(country: "France", city: "Paris", postal_code: "75008", street: "8 rue Chambiges")
bob.addresses.create!(country: "Germany", city: "Berlin", postal_code: "10551", street: "Tiergarten")

Rails 3

预加载数据时，通常你都会选择#includes，大概由于从 Rails 2 甚至 Rails 1 开始，就推荐使用该方法了。它会魔法般地生成两个查询：

User.includes(:addresses)
#  SELECT "users".* FROM "users" 
#  SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" IN (1, 2)

另外两个方法呢？我们先来看它们的实际表现。

User.preload(:addresses)
#  SELECT "users".* FROM "users" 
#  SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" IN (1, 2)

到底是#preload类似于#includes呢？还是#includes类似于#preload？请继续阅读。

#eager_load行为如下：

User.eager_load(:addresses)

#  SELECT
#  "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4, 
#  "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7 
#  FROM "users" 
#  LEFT OUTER JOIN "addresses" ON "addresses"."user_id" = "users"."id"

结果完全不一样，对吧。问题的关键在于 Rails 有两种方式进行数据预加载：一种通过单独的（separate）查询去加载其他表的数据；另一种只用单个查询 (带left join) 一次性加载所有数据。

用#preload，就意味着你希望总是用单独的（separate）查询；用#eager_load，表明你用的是单个查询（一次性加载所有数据）。那么#includes呢？它会帮你选择从上面选择一种方式，即你把决定权交给了 Rails。那么它是根据什么决定的呢？你可能会问，是基于查询条件 (query conditions)。我们先来看这样一个例子：#includes把查询代理给了#eager_load，所以只会有一个巨型查询产生。

# 这两个用法是等效的
 User.includes(:addresses).where("addresses.country = ?", "Poland")
 User.eager_load(:addresses).where("addresses.country = ?", "Poland")

# SELECT 
# "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4,
# "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7 
# FROM "users"
# LEFT OUTER JOIN "addresses" 
# ON "addresses"."user_id" = "users"."id" 
# WHERE (addresses.country = 'Poland')

本例中 Rails 发现where语句用到了预加载表（addresses）中的列（country），故而将#includes代理给了#eager_load。你也可直接调用#eager_load,来到稳定实现这个效果。

如果显示调用#preload会怎样呢？

User.preload(:addresses).where("addresses.country = ?", "Poland")
#  SELECT "users".* FROM "users" WHERE (addresses.country = 'Poland')
#
#  SQLite3::SQLException: no such column: addresses.country

由于没将users表和addresses表关联（join）起来，故而抛出了异常。

目标实现了吗

如果你再看下这个例子

User.includes(:addresses).where("addresses.country = ?", "Poland")

你可能会问：这些代码初衷是啥？作者这样写想表达啥？我们将用简洁的 Rails 代码来达成以下目标：

1. 找出带波兰地址的用户，且只预加载其波兰地址； 2. 找出带波兰地址的用户，但预加载其所有地址； 3. 找出所有的用户，但只预加载其波兰地址。

你知道我们已实现了其中哪一个目标吗？第一个。下面来看看能否实现后面两个。

`#preload`有啥优势

当前任务：找出带波兰地址的用户，但预加载其所有地址。即是需要找出那些至少有一个波兰地址的用户，及其所有地址。

我们只需要那些有波兰地址的用户，这很简单：User.joins(:addresses).where("addresses.country = ?", "Poland")；要预加载地址，再加上includes(:addresses)就够了嘛，对吧？

r = User.joins(:addresses).where("addresses.country = ?", "Poland").includes(:addresses)

r[0]
#=> #<User id: 1, name: "Robert Pankowecki", email: "robert@example.org", created_at: "2013-12-08 11:26:24", updated_at: "2013-12-08 11:26:24"> 

r[0].addresses
# [
#   #<Address id: 1, user_id: 1, country: "Poland", street: "Rynek", postal_code: "55-555", city: "Wrocław", created_at: "2013-12-08 11:26:50", updated_at: "2013-12-08 11:26:50">
# ]

然而，事实并非我们所想的那样：结果中少了了第二个地址，此处它本该出现的。Rails 再次探测到 Where语句使用了预加载了的表 (addresses)，因而底层还是用#eager_load来实现#includes的。唯一的区别是这里使用的是INNER JOIN而非前面的LEFT JOIN，但查询结果并非没啥区别。

SELECT 
"users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4,
"addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7 
FROM "users"
INNER JOIN "addresses" 
ON "addresses"."user_id" = "users"."id" 
WHERE (addresses.country = 'Poland')

难得有机会比 Rails 还“聪明”，我们可以显示地调用#preload而非#includes来表明我们的意图：

r = User.joins(:addresses).where("addresses.country = ?", "Poland").preload(:addresses)

# SELECT "users".* FROM "users"
# INNER JOIN "addresses" ON "addresses"."user_id" = "users"."id" 
# WHERE (addresses.country = 'Poland')

# SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" IN (1)

r[0] 
# [#<User id: 1, name: "Robert Pankowecki", email: "robert@example.org", created_at: "2013-12-08 11:26:24", updated_at: "2013-12-08 11:26:24">] 

r[0].addresses
# [
#  <Address id: 1, user_id: 1, country: "Poland", street: "Rynek", postal_code: "55-555", city: "Wrocław", created_at: "2013-12-08 11:26:50", updated_at: "2013-12-08 11:26:50">,
#  <Address id: 3, user_id: 1, country: "France", street: "8 rue Chambiges", postal_code: "75008", city: "Paris", created_at: "2013-12-08 11:36:30", updated_at: "2013-12-08 11:36:30">] 
# ]

这正是我们想要的。借助#preload，我们不必再将 user 查询条件和数据预加载混淆在一起了，查询再次变得自然而简洁。

预加载关联数据子集 (Preloading subset of association)

当前任务：查找所有所有用户，但只预加载其波兰地址。

说实话，我不喜欢仅预加载关联数据子集，因为程序其他部分还是可能会误认为关联数据已经全加载了（基于该假设做出的决策，自然也是错的）。若获取关联数据子集用于展示，倒还说得过去。

我更倾向于直接在关联上加条件：

class User < ActiveRecord::Base
  has_many :addresses
  has_many :polish_addresses, conditions: {country: "Poland"}, class_name: "Address"
end

接着，我们便可显示预加载关联数据了：

r = User.preload(:polish_addresses)

# SELECT "users".* FROM "users" 
# SELECT "addresses".* FROM "addresses" WHERE "addresses"."country" = 'Poland' AND "addresses"."user_id" IN (1, 2)

r

# [
#   <User id: 1, name: "Robert Pankowecki", email: "robert@example.org", created_at: "2013-12-08 11:26:24", updated_at: "2013-12-08 11:26:24">
#   <User id: 2, name: "Bob Doe", email: "bob@example.org", created_at: "2013-12-08 11:26:25", updated_at: "2013-12-08 11:26:25">
# ] 

r[0].polish_addresses

# [
#   #<Address id: 1, user_id: 1, country: "Poland", street: "Rynek", postal_code: "55-555", city: "Wrocław", created_at: "2013-12-08 11:26:50", updated_at: "2013-12-08 11:26:50">
# ] 

r[1].polish_addresses
# []

或者：

r = User.eager_load(:polish_addresses)

# SELECT "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4, 
#        "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7
# FROM "users" 
# LEFT OUTER JOIN "addresses" 
# ON "addresses"."user_id" = "users"."id" AND "addresses"."country" = 'Poland'

r
# [
#   #<User id: 1, name: "Robert Pankowecki", email: "robert@example.org", created_at: "2013-12-08 11:26:24", updated_at: "2013-12-08 11:26:24">,
#   #<User id: 2, name: "Bob Doe", email: "bob@example.org", created_at: "2013-12-08 11:26:25", updated_at: "2013-12-08 11:26:25">
# ]

r[0].polish_addresses
# [
#   #<Address id: 1, user_id: 1, country: "Poland", street: "Rynek", postal_code: "55-555", city: "Wrocław", created_at: "2013-12-08 11:26:50", updated_at: "2013-12-08 11:26:50">
# ]

r[1].polish_addresses
# []

换做是我们，只在运行时才知道要应用的关联条件，我们该怎么做？实话说我不知道，如果你知道，请在评论中告知。

最后一个目标

你可能会问：区区一个预加载为啥就这么麻烦？我也不清楚，不过我想大部分ORM初衷都是生成单条查询、从单张表中加载数据。有了预加载，情况就复杂多了：它致使我们用多条件的查询从多张表中去加载多类数据。Rails 中，我们采用链式 API 来构建多个查询 (比如#preload)。

若问我想要什么样的 API？类似下面这样的：

User.joins(:addresses).where("addresses.country = ?", "Poland").preload do |users|
  users.preload(:addresses).where("addresses.country = ?", "Germany")
  users.preload(:lists) do |lists|
    lists.preload(:tasks).where("tasks.state = ?", "unfinished")
  end
end

我希望你能明白我的心思，但这仅是理想，还是让我们回到现实中来吧。

Rails 4 中的变化

现在我们来说说 Rails 4 中有关预加载的变化。

class User < ActiveRecord::Base
  has_many :addresses
  has_many :polish_addresses, -> {where(country: "Poland")}, class_name: "Address"
end

现在 Rails 推荐你使用新的lambda语法来定义关联条件。这个改进相当棒，因为我不止一次看到这样的错误：关联条件相关代码只在类加载时被解释执行了一次 (关联中含有 Date.today 的代码就会出错)。

Rails 同样推荐你使用lambda语法或method语法去定义 scope。

# 差，Time.now 会一直停留在class加载的时刻（相对于成了一个“死”值了，而非动态变化的）
# 并且在开发环境中，这个bug还不容易发现，因为一旦类有修改，开发环境便会自动重新加载代码（掩盖了“死”值的真相）
scope :from_the_past, where("happens_at <= ?", Time.now)

# 好
scope :from_the_past, -> { where("happens_at <= ?", Time.now) }

# 好
def self.from_the_past
  where("happens_at <= ?", Time.now)
end

无论是动态解释，还是只在一开始解释一次，我们的条件where(country: "Poland")都是一样的。但 Rails 尝试统一两种场景（关联、scope）的语法总是好的，从而避免我们再犯类似的错误。

说完了语法上的变化，下面来看看行为上的改变。

User.includes(:addresses)
#  SELECT"users".* FROM "users"
#  SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" IN (1, 2)

User.preload(:addresses)
#  SELECT "users".* FROM "users"
#  SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" IN (1, 2)

User.eager_load(:addresses)

#  SELECT "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4,
#         "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7
#  FROM "users"
#  LEFT OUTER JOIN "addresses"
#  ON "addresses"."user_id" = "users"."id"

好吧，看起来还是一样，这倒不奇怪。试着加上先前让我们麻烦不断的查询条件看看：

  User.includes(:addresses).where("addresses.country = ?", "Poland")
 # 
  #弃用警告: 貌似你预加载了SQL字符串代码片段中引用的（referenced）表（users或addresses），例如：
  #
  #    Post.includes(:comments).where("comments.title = 'foo'")
  #
  # 目前，Active Record识别出来了字符串中的表（comments），并且知道将其JOIN到整个大查询中，而非单独弄一条查询出来。然而，没有成熟的SQL解析器支持的情况下，这样做是有天然缺陷的。显然我们不会实现SQL解析器，所以将移除此特性。从今以后，引用（reference）字符串中的表时，你得显示告诉Active Record：
  #
  #   Post.includes(:comments).where("comments.title = 'foo'").references(:comments)
  # 
  # 如果你用不着这个隐式join引用表的特性，你可以通过如下设置来完全禁用它：`config.active_record.disable_implicit_join_references = true`.
#
  # SELECT "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4,
  #        "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7
  # FROM "users" 
  # LEFT OUTER JOIN "addresses" ON "addresses"."user_id" = "users"."id" 
  # WHERE (addresses.country = 'Poland')

咦，看起来真啰嗦！不过建议你还是仔细读一下，因为它把其中情理解释得很清楚。

换句话说，Rails 不愿像以前那样聪明了——即不再会通过探测where条件来决定用哪一种查询策略了，它需要我们的帮助。我们得告诉它某张表有条件查询，就像这样：

User.includes(:addresses).where("addresses.country = ?", "Poland").references(:addresses)

我很好奇如果我们尝试预加载多张表，但只显示引用（reference）了其中一张表会怎样？

User.includes(:addresses, :places).where("addresses.country = ?", "Poland").references(:addresses)

#  SELECT "users"."id" AS t0_r0, "users"."name" AS t0_r1, "users"."email" AS t0_r2, "users"."created_at" AS t0_r3, "users"."updated_at" AS t0_r4, 
#         "addresses"."id" AS t1_r0, "addresses"."user_id" AS t1_r1, "addresses"."country" AS t1_r2, "addresses"."street" AS t1_r3, "addresses"."postal_code" AS t1_r4, "addresses"."city" AS t1_r5, "addresses"."created_at" AS t1_r6, "addresses"."updated_at" AS t1_r7,
#         "places"."id" AS t2_r0, "places"."user_id" AS t2_r1, "places"."name" AS t2_r2, "places"."created_at" AS t2_r3, "places"."updated_at" AS t2_r4 
#  FROM "users" 
#  LEFT OUTER JOIN "addresses" ON "addresses"."user_id" = "users"."id" 
#  LEFT OUTER JOIN "places" ON "places"."user_id" = "users"."id" 
#  WHERE (addresses.country = 'Poland')

我们本以为它会用#eager_load策略（通过LEFT JOIN）去加载addresses，用#preload策略（单独的查询）去加载places。但是你也看到了，事实并非如此。可能以后这个行为会改变。

如果显示使用#eager_load去预加载数据，Rails4 是不会警告你加#references的，生成的查询也一样。

User.eager_load(:addresses).where("addresses.country = ?", "Poland")

换言之，下面两种写法是等效的：

User.includes(:addresses).where("addresses.country = ?", "Poland").references(:addresses)
User.eager_load(:addresses).where("addresses.country = ?", "Poland")

对于#preload，行为还是一样（和 Rails4 以前一样）。

User.preload(:addresses).where("addresses.country = ?", "Poland")
#  SELECT "users".* FROM "users" WHERE (addresses.country = 'Poland')
#
#  SQLite3::SQLException: no such column: addresses.country: SELECT "users".* FROM "users"  WHERE (addresses.country = 'Poland')

前面提到的其他查询，在 Rails4 中表现也是一样的：

# 找出带波兰地址的用户，但预加载其所有地址；
User.joins(:addresses).where("addresses.country = ?", "Poland").preload(:addresses)

#找出所有的用户，但只预加载其波兰地址；
User.preload(:polish_addresses)

下面这些方法的文档，在 Rails3 中已缺失多年了，终于在 Rails4 补上了：

小结

Rails 有 3 种数据预加载方式：

1. #includes 2. #preload 3. #eager_load

#includes会根据是否有预加载表相关的查询条件，来决定代理给#preload还是#eager_load。

#preload总是会用单独的数据库查询来预加载数据。

#eager_load会用LEFT JOIN联结每个预加载表，从而形成单个巨型查询。

Rails4 中，如果有预加载表相关查询条件，那么你应该结合使#references来使用#includes。

喜欢本文吗？你也可能对我们的Rails 书籍感兴趣：

一个 includes (:column_name) 的小陷阱

qinfanpeng — Sat, 28 Nov 2015 12:17:50 +0800

路人皆知 Rails 可用includes用来避免N+1问题，但我最近就因 includes 献了一回丑。

class TransactionHistory < ActiveRecord::Base
  has_many :transaction_items
  scope :with_item_named_after, ->(item_name) { joins(:transaction_items).merge TransactionItem.named_after(item_name) }
end

class TransactionItem < ActiveRecord::Base
  belongs_to :transaction_history
  scope :named_after, ->(name) { where(name: name) }
end

现假设我们需要根据 item_name 来过滤 transaction_hitory，只要 transaction_hitory 中有 transaction_item 满足条件就行，但是为了信息完整也要显示匹配 transaction_hitory 中那些不匹配的 transaction_item。

第一次不假思索地写出了下面的代码：

# Controller
@transaction_histories = TransactionHistory.with_item_named_after(params[:query][:item_name]).includes(:transaction_items)

# View
<%- @transaction_histories.each do |transaction_history| %>
  <!-- ... -->
  <%= transaction_history.transaction_number %>
  <!-- ... -->
  <%- transaction_history.transaction_items.each do |transaction_item| %>
    <%= transaction_item.name %>
  <%- end %>
<%- end %>

不幸的是，这并不好使。用 item_name 去过滤，transaction_history 列表倒是对了，但每条 transaction_history 只显示了那些匹配的 transaction_item。这非我所愿。

transaction_history = create :transaction_history
item_1 = transaction_history.transaction_items.create name: 'item_1'
item_2 = transaction_history.transaction_items.create name: 'item_2'

# 下面这行代码返回的transaction_history里面就只包含了item_1，而没包含item_2
TransactionHistory.with_item_named_after('item_1').includes(:transaction_items)

 # 去掉解决 N+1问题的 includes(:items) 就对了，但我们的确需要解决 N+1。
TransactionHistory.with_item_named_after('item_1')

TransactionHistory.with_item_named_after('item_1').includes(:transaction_items)生成的 SQL 类似这样：

而TransactionHistory.with_item_named_after('item_1')生成的 SQL 却类似这样：

现在能想到的办法如下，不够优雅，且分成了两次查询，Rails 如此优雅的东西，肯定有更优雅的解决方案。若有人有漂亮的解决方案，请一定告诉我，不甚感激。

class TransactionHistory < ActiveRecord::Base
  has_many :transaction_items
  scope :with_item_named_after, ->(item_name) do
    matched_transaction_item_ids = TransactionItem.named_after(item_name).map(&:id).uniq
    where(id: matched_transaction_item_ids)
  end 
end

听我啰嗦了这么久，最后推荐一个N+1 嗅探 gem 包表示感谢： bullet 。

另外，可能你也没从这学到啥东西，推荐几篇文章，表示我的歉意：

qinfanpeng (qinfanpeng)

拒绝高考冲刺 12 年， 志愿填写 12 分

选专业的常见错误

挑选候选专业

审视候选专业

大体了解候选专业

了解候选专业所学课程

了解候选专业相关工作

如何填报第二志愿

重要参考资料

[译] React setState 的麻烦事儿

setState() 门事件

React setState() 解惑

setState() 究竟有何问题？

从属 State（Dependent State）

仅仅是新手才有的问题吗？

在渲染之前决定 State

setState() 该怎么治？

setState() 为何如此严苛？

何时使用 setState()？

接下来

《优雅的 Ruby》40 页抢鲜试读

《Ruby 元编程》《Ruby 原理剖析》的姊妹篇《优雅的 Ruby》上天猫了

Ruby 就是为了让程序员快乐编程而生的。 —— 松本行弘（Matz）

若只如初见

遭遇现实

重拾快乐

Redux Actions & Redux Thunk

Agenda

Agenda

Rails REST Routes

Rails Controller & Actions

Describe Redux Action in One Sentence

FSA(Flux Standard Action)

Flux Standard Action Specifications

Benefit of using FSA

Use Action Literal Directly

Encapsulate Action in Action Creator

Todo Actions (by Action Creators)

Use redux-actions to Simplify Action Creator

Common Misuse of redux-actions

the Way to use redux-actions

use redux-promise to Call API

use redux-thunk to Call API

use redux-thunk to Conditional Dispatch

Use redux-thunk to Dispatch Multiple Actions at Once

Overuse redux-thunk

Overuse redux-thunk

Overuse reason ?

react-redux will auto use bindActionCreators

redux-thunk Source Code

Fix The Overuse of redux-thunk

Thank You & QA

以前端工程师的视角看代码质量

常见重构手法 (下)

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 (用卫语句替换嵌套条件表达式)

消除条件嵌套

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

简化取反后的条件

使用 if-else 的注意事项

拒绝高考冲刺 12 年，志愿填写 12 分

react-redux will auto use `bindActionCreators`