这个文集的系列是关于《JavaScript设计模式于开发实践》一书，建议大家在厌倦业务代码的时候可以看看，受益匪浅。
从第一章看到第十三章，津津有味，但是过目就忘，毕竟这样的例子在实际应用中还需要灵活变通。就好比学习高数，你学会了一个方程式的解题方法和过程，但是同样的问题放到实际的物理模型中，未必能马上发现其中的解法。
多次阅读，在思考问题时慢慢代入设计模式的思维，在重构时遵循其中的法则，这就是大神们常说的“你应该这样做”。为什么突然就停下来写这节职责链模式呢？归功于下面这段代码（题目和代码均从书中摘取）。
假设我们负责一个售卖手机的电商网站，经过分别交纳500元定金和200元定金的两轮预定后（订单在此时生成），现在已经到了正式购买的阶段。
公司针对支付过定金的用户有一定的优惠政策。在正式购买后，已经支付过500元定金的用户会收到100元的商城优惠券，200元定金的用户可以收到50元的优惠券，而之前没有支付定金的用户只能进入普通购买模式，也就是没有优惠券，而且库存有限的情况下不一定保证能买到。
这里简略地描述一下...
orderType: 订单类型 | 1 => 500元定金用户, 2 => 200元定金用户, 3 => 普通购买用户
pay: 是否已经支付定金。（如果用户下过500/200元定金订单但是没有支付，降级为普通购买模式）
stock: 表示当前用于普通购买地手机库存数量，已经支付过定金地用户不受限制
//代码实现
var oder = function( orderType, pay, stock) {
if( orderType === 1 ) { // 500元定金购买模式
if ( pay === true ) {
console.log('500元定金预购，得到100元优惠券');
}else {
if ( stock > 0 ) {
console.log('普通购买， 无优惠券');
}else {
console.log('手机库存不足');
}
}
}
else if ( orderType === 2 ) { // 200元定金购买模式
if ( pay === true ) {
console.log('200元定金预购，得到50元优惠券');
}else {
if ( stock > 0 ) {
console.log('普通购买， 无优惠券');
}else {
console.log('手机库存不足');
}
}
}
else if ( orderType === 3 ) { // 200元定金购买模式
if ( stock > 0 ) {
console.log('普通购买， 无优惠券');
}else {
console.log('手机库存不足');
}
}
};
order(1, true, 500); //输出： 500元定金预购，得到100元优惠券
作者评论这段代码： 恐怕只有最“新手”地程序员才会写出这样的代码。
于是我很尴尬地想： 哈哈，算我一个。
实习期间，我面临的实际情况稍复杂一点，简单描述一下：
一个产品管理系统，第一层分支便是 不同系列的产品 ，第二层分支是 不同角色 ，第三层分支便是对应的action（这层相当于上面的log，可以不列入在内）。
那么在没有真正熟悉整个流程的情况下，我常常会写出else-if许多分支，这些分支往往一开始没有那么多（一般一开始只有2钟情况，3个的时候一般会考虑功能的封装等等状况了），往往项目往前走，会临时地加入一些状况，else-if分支开始爆炸，每写一行代码就像在牛粪上种花，你都不愿意回头欣赏这些“花”。
整个过程就像温水里的青蛙，你能怪产品烧的水么？产品说，我也没盖锅盖呀，你自己没意识到要及时跳出来么？
思考
1.如果接到新需求，如何意识到代码需要重构？
2.如果需要重构，如何有前瞻性的将代码重构好？
曾经读过一句话： 代码只能重构一次。
作为一个不合格的程序员，我花过大把的时间重构，深知其中的痛苦。
level5的时候， 我会尝试2遍重构
- 代码整理+注释整理
- 功能分离
level6的时候， 我看透了代码重构是模式上的变化，于是我不再去改动一些功能性代码，例如交互事件
- 解耦代码、处理违反封闭-开放原则的代码
level7的时候，我还没做到。我不改了，因为这只会让你厌恶你最喜欢的东西。
最后，真心推荐这本书《JavaScript设计模式与开发实践》，拯救业务代码中天天抱怨的你。
