前端重构感想
考拉PC前端重构之路
@(重构)[组件化|拆分]javascript
代码重构是一个产品不断的功能迭代过程当中，不可避免的一项工做。所谓重构，是在不改变程序的输入输出即保证现有功能的状况下，对内部实现进行优化和调整。 每一个开发人员从业生涯中，或多或少的作太重构工做。小到重写一个功能函数、业务组件，大到重构一个复杂功能模块或整站重构。html
重构是须要花费必定成本和精力的，尤为是一个有各类历史遗留问题（用的老旧框架或工具）、又糅杂了各类业务逻辑（有些功能逻辑连需求方都未必清楚）、且可读性及维护性都不好的重要功能模块，好比考拉的下单页，不动，每次功能迭代的时候都有想撞墙的心，大动，又是不小的工做量，且有必定的风险。固然长痛不如短痛，长远来看，重构势在必行。前端
why 重构
- 设计不合理or全无设计 ：原来的实现方式不合理，或者全无模块拆分、组件提取意识的开发模式，纯粹的业务逻辑堆叠式开发，会致使功能没法重用，代码冗余，不利于维护。
- 页面结构与功能实现耦合 ：脚本文件中夹杂着各类html结构，表现和行为不分离，致使代码可读性和维护性大大降低。（我不会告诉你旧版考拉下单页的入口脚本有2000多行，cry~）。
- 代码难以理解 ：页面没有清晰的入口函数，函数调用关系混乱，不管改bug仍是迭代新功能，面对难以理解的代码，开发效率低下。
- 代码引发性能问题：不合理的实现方式或者大量无用冗余的代码，引发了明显性能问题的，须要即时重构优化。
- 框架or类库更新：前端的技术框架突飞猛进，在选择或者淘汰不合适项目的第三方库的时候，也涉及到重构工做。
when 重构
重构工做实际上是随时均可进行的。当你以为代码可读性变差、重用性及可维护性下降时，都应该有意识的去作重构。在大部分的项目中，如下将是重构的合理时间点：java
- 功能迭代时：当添加一个功能时，发现原有的设计没法知足新需求，能够考虑重构；在设计功能组件的时候，能够为将来可能的需求预留接口；
- 修复bug的时候：bug产生以后，须要思考是不是不合理的编码致使的问题而不仅仅是以解决bug算完事（固然线上重大bug天然以即时修复为第一要务），能够借助修复bug的契机，把业务逻辑整理清晰，必要时能够找后端配合改接口；
- code Review阶段：此阶段距离提测时间每每较近，但若是是明显不合理的实现思路，宁愿delay也要从新设计实现；若是前期思考充分，通常不会出现此类状况，大部分是在给其余人review的时候，发现不可理解、可读性差，这也是须要进一步修改重写的。
固然在需求紧急的时候，是不适合作重构的。后端
do重构
以考拉下单页重构为例。bash
但凡重构，必需要对已有业务逻辑有较充分的了解，评估重构的影响面及可能的风险， 列出基本功能点（也可做为QA的测试回归点），保证重构后不要有功能遗漏，不改变现有功能。框架
如何了解已有业务逻辑？异步
- 跑线上流程；（有些特殊逻辑，模拟困难）
- 对照现有的交互稿；（不断的功能迭代，可能找不到完整的交互稿）
- 读懂已有代码；（全面了解业务逻辑最好的方法，可是耗时）
- 询问以前的开发者；（如已离职，查找是否有交接文档之类）
功能模块拆分
在对业务逻辑有充分了解以后，能够进行功能拆分，把可重用的、功能独立的业务逻辑做为组件或公用模板提取，同时须要考虑组件之间的相互影响。拆分以后，能够多人并行开发，约定好外部调用组件的接口便可。
如下是下单页的功能模块拆分：函数
根据同步字段orderType，来肯定是普通商品订单仍是帐号充值订单，并初始化对应的组件；根据同步信息，异步获取下单信息（含商品信息及结算信息）；若是是普通商品订单，服务端会根据用户所选地址进行拆单，返回拆单后的商品和结算信息。按功能拆分后，组件及组件的嵌套关系以下：工具
下单页目录结构：
javascript
|——components
| |——address/address.js //地址控件
| |——checkcode/checkcode.js //验证码控件
|——page/order
| |——order_confirm.js //入口脚本
| |——components
| | |——confirmGoods.js+html //确认商品信息
| | |——settlement.js+html //结算信息
| | |——exchangeCoupon.js+html //兑换优惠券
| | |——rechargeInfo.js+html //帐号充值
| | |——invoiceInfo.js+html //发票信息
| | |——invoice.js+html //设置发票
| | |——bean.html //考拉豆抵扣
| | |——feeList.html //运费税费列表
| | |——gift.html //赠品信息
| | |——useCoupon.js+html //使用优惠券
| | |——submitCB.js //提交回调
| |——widget
| | |——popCoupon.js //弹窗领券复制代码
after 重构
- 入口明确，调用关系清晰，查找方便
- 功能实现与结构不耦合，可读性加强
- 组件化后，有利于功能重用
- 提高了编码体验，维护及功能迭代再也不感受煎熬o(^▽^)o
last
重构历来不是一次性行为，是咱们须要不断进行的工做。多人维护以及不断的功能迭代以后，代码多多少少都会有优化的空间，因此在你看到不合理或任何值得重构的地方时，行动起来吧，去优化，不要等到重构的成本更大时再进行，由于那会更痛，不要问我怎么知道。