为什么重构？ 因为闻到了代码的坏味道， 这些坏味道具体表现在：

1. Duplicated Code 重复代码： 自己遇到业务场景 之前做wap 上拉刷新功能， 我先在一个地方实现， 因为没有及时拿出来做成组件来调用， 导致拥有上拉刷新功能的不同页面都需要重复这个代码。非常不利于维护。 改进方案是：做成组件，特定需求， 传递参数进去。
2. Long Method 过长函数，程序越长， 越难理解，成正相关姿态， 给小函数起一个好名字， 就能做到通过理解名字了解函数作用， 根本不必去看其中写了什么：自己遇到业务场景：有实现过一个上传excel文件数据的功能， 上传后需要对上传的多行数据校验， 因为数据类型比较多， 多个判断， 自己写在一个函数中。 每次修改部分功能， 都是折磨。逻辑复杂，不利于写于健壮的代码。改进方案是：用小函数拆分逻辑，保证小函数的正确性。
3. Large Class 过大的类：暂时没遇到过
4. Long Parameter List(过长参数列) [缺点：太长的参数列难以理解， 太多参数会造成前后不一致， 不容易使用]: 想到一点， jquery插件一般都要有很多配置项， 现行的解决方案是, 将配置项全部写入一个object{}中， 将这个object传入插件对象。
5. Divergent Change 散发式变化

工作计划

• Mercury
• Venus
• Earth (Orbit/Moon)
• Mars
• Jupiter
• Saturn
• Uranus
• Neptune
• Comet Haley

为什么重构？ 因为闻到了代码的坏味道， 这些坏味道具体表现在：

1. Duplicated Code 重复代码： 自己遇到业务场景 之前做wap 上拉刷新功能， 我先在一个地方实现， 因为没有及时拿出来做成组件来调用， 导致拥有上拉刷新功能的不同页面都需要重复这个代码。非常不利于维护。 改进方案是：做成组件，特定需求， 传递参数进去。
2. Long Method 过长函数，程序越长， 越难理解，成正相关姿态， 给小函数起一个好名字， 就能做到通过理解名字了解函数作用， 根本不必去看其中写了什么：自己遇到业务场景：有实现过一个上传excel文件数据的功能， 上传后需要对上传的多行数据校验， 因为数据类型比较多， 多个判断， 自己写在一个函数中。 每次修改部分功能， 都是折磨。逻辑复杂，不利于写于健壮的代码。改进方案是：用小函数拆分逻辑，保证小函数的正确性。
3. Large Class 过大的类：暂时没遇到过
4. Long Parameter List(过长参数列) [缺点：太长的参数列难以理解， 太多参数会造成前后不一致， 不容易使用]: 想到一点， jquery插件一般都要有很多配置项， 现行的解决方案是, 将配置项全部写入一个object{}中， 将这个object传入插件对象。
5. Divergent Change 散发式变化