前端重構感想

考拉PC前端重構之路

@(重構)[組件化|拆分]

代碼重構是一個產品不斷的功能迭代過程當中，不可避免的一項工做。所謂重構，是在不改變程序的輸入輸出即保證現有功能的狀況下，對內部實現進行優化和調整。 每一個開發人員從業生涯中，或多或少的作太重構工做。小到重寫一個功能函數、業務組件，大到重構一個複雜功能模塊或整站重構。

重構是須要花費必定成本和精力的，尤爲是一個有各類歷史遺留問題（用的老舊框架或工具）、又糅雜了各類業務邏輯（有些功能邏輯連需求方都未必清楚）、且可讀性及維護性都不好的重要功能模塊，好比考拉的下單頁，不動，每次功能迭代的時候都有想撞牆的心，大動，又是不小的工做量，且有必定的風險。固然長痛不如短痛，長遠來看，重構勢在必行。

why 重構

• 設計不合理or全無設計 ：原來的實現方式不合理，或者全無模塊拆分、組件提取意識的開發模式，純粹的業務邏輯堆疊式開發，會致使功能沒法重用，代碼冗餘，不利於維護。
• 頁面結構與功能實現耦合 ：腳本文件中夾雜着各類html結構，表現和行爲不分離，致使代碼可讀性和維護性大大降低。（我不會告訴你舊版考拉下單頁的入口腳本有2000多行，cry~）。
• 代碼難以理解 ：頁面沒有清晰的入口函數，函數調用關係混亂，不管改bug仍是迭代新功能，面對難以理解的代碼，開發效率低下。
• 代碼引發性能問題：不合理的實現方式或者大量無用冗餘的代碼，引發了明顯性能問題的，須要即時重構優化。
• 框架or類庫更新：前端的技術框架突飛猛進，在選擇或者淘汰不合適項目的第三方庫的時候，也涉及到重構工做。

when 重構

重構工做實際上是隨時均可進行的。當你以爲代碼可讀性變差、重用性及可維護性下降時，都應該有意識的去作重構。在大部分的項目中，如下將是重構的合理時間點：

• 功能迭代時：當添加一個功能時，發現原有的設計沒法知足新需求，能夠考慮重構；在設計功能組件的時候，能夠爲將來可能的需求預留接口；
• 修復bug的時候：bug產生以後，須要思考是不是不合理的編碼致使的問題而不僅僅是以解決bug算完事（固然線上重大bug天然以即時修復爲第一要務），能夠藉助修復bug的契機，把業務邏輯整理清晰，必要時能夠找後端配合改接口；
• code Review階段：此階段距離提測時間每每較近，但若是是明顯不合理的實現思路，寧願delay也要從新設計實現；若是前期思考充分，通常不會出現此類狀況，大部分是在給其餘人review的時候，發現不可理解、可讀性差，這也是須要進一步修改重寫的。

固然在需求緊急的時候，是不適合作重構的。

---

do重構

以考拉下單頁重構爲例。

但凡重構，必需要對已有業務邏輯有較充分的瞭解，評估重構的影響面及可能的風險， 列出基本功能點（也可做爲QA的測試迴歸點），保證重構後不要有功能遺漏，不改變現有功能。

如何瞭解已有業務邏輯？

• 跑線上流程；（有些特殊邏輯，模擬困難）
• 對照現有的交互稿；（不斷的功能迭代，可能找不到完整的交互稿）
• 讀懂已有代碼；（全面瞭解業務邏輯最好的方法，可是耗時）
• 詢問以前的開發者；（如已離職，查找是否有交接文檔之類）

功能模塊拆分

在對業務邏輯有充分了解以後，能夠進行功能拆分，把可重用的、功能獨立的業務邏輯做爲組件或公用模板提取，同時須要考慮組件之間的相互影響。拆分以後，能夠多人並行開發，約定好外部調用組件的接口便可。
如下是下單頁的功能模塊拆分：

enter image description here

根據同步字段orderType，來肯定是普通商品訂單仍是帳號充值訂單，並初始化對應的組件；根據同步信息，異步獲取下單信息（含商品信息及結算信息）；若是是普通商品訂單，服務端會根據用戶所選地址進行拆單，返回拆單後的商品和結算信息。按功能拆分後，組件及組件的嵌套關係以下：

enter image description here

下單頁目錄結構：

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

重構歷來不是一次性行爲，是咱們須要不斷進行的工做。多人維護以及不斷的功能迭代以後，代碼多多少少都會有優化的空間，因此在你看到不合理或任何值得重構的地方時，行動起來吧，去優化，不要等到重構的成本更大時再進行，由於那會更痛，不要問我怎麼知道。