前言
代碼重構是業內經常討論的一個熱門話題，重構指的是在不改變代碼外部行為的情況下進行源代碼修改，所以重構之前需要考慮的是重構后如何才能保證外部行為不改變。對於后端代碼來說，可以通過大量的自動化測試來確保重構后的代碼邏輯，可對於普遍缺乏自動化測試的前端代碼來說，重構之前一定要考慮再三才能下手。
有效地重構代碼
我曾經有一次不算太成功的前端重構經歷，所幸的是沒有導致太大的問題，但教訓是慘痛的。此次重構的項目本身沒有足夠的自動化測試，尤其是針對前端的自動化測試，所以在重構之前也預想到了重構的風險。先來介紹重構之前項目存在的問題：項目的前端代碼沒有統一的規范，所以不同人開發的模塊對應的代碼風格完全不同，即使有相同的邏輯也是由完全不同的代碼實現的；而且，不同模塊的代碼寫到了相同的代碼文件中，使得文件的代碼量很大；項目的功能較多，所以前端代碼量大，代碼的文件也多，又由於需求變更頻繁，所以代碼中的無用代碼量多；網站首頁加載時間過長，平均加載時間超過5秒；部分動態模塊的加載會導致頁面假死。總體來說項目代碼存在的問題就是維護性差和性能差，如果要持續地添加新功能就有必要重構現有的代碼。
鑒於項目代碼的實際情況，並且考慮到缺乏足夠的自動化測試，所以我權衡了又權衡，最終決定先嘗試對前端的部分代碼進行重構，重構的過程主要分為如下幾個步驟：
（1）刪除無用代碼，精簡代碼。
無用的代碼主要集中在CSS和JavaScript文件中，包括已經不起作用的CSS樣式和廢棄的JavaScript函數。這個重構過程是最吃力不討好的過程，修改的過程需要小心翼翼，不停地查看函數和變量在上下文的調用關系，以免錯刪代碼。總體來說，這個階段的重構還是利大於弊，雖然后續發現了一些由於誤刪而導致的Bug，但是刪除了廢棄的代碼，提高了后續的可維護性。
（2）前端代碼規范化。
頁面的HTML標簽中還有大量的內聯CSS樣式，有些頁面的head部分也有CSS樣式，需要把這些CSS放到獨立的文件中；調整代碼的層次縮進格式，不同層級按照4個空格來縮進；更改標准已不推薦的標簽，如<center> <b>等，改為由CSS樣式控制；統一命名規則，這里主要涉及HTML中的id和class名稱；另外，在JavaScript中集中定義局部變量，並把部分全局變量轉變為局部變量，縮小了變量的作用域。
（3）整理基礎類庫。
網站初期為了加快開發的進度而引入了多個框架，其中包括Extjs、JQuery以及多個JQuery插件。Extjs和JQuery中重復的功能較多，項目中很多相同的實現使用的是不同類庫中的功能，如：DOM選擇、Ajax請求等。部分jQuery的UI插件的功能也和Extjs中的功能重復。鑒於項目的狀況，只能保守選擇同時保留Extjs和jQuery。重構的內容是統一UI插件的使用、統一基礎方法的使用。
（4）前端代碼模塊化。
按照模塊歸類CSS代碼，放到模塊對應的單獨CSS文件中；按照模塊分離JavaScript代碼，按照模塊定義不同的命名空間；將JavaScript代碼中的公共方法歸類到獨立的的共通文件中，同時引入面向對象的思想重構JavaScript代碼，進一步明確公有接口和私有接口。
（5）提高頁面加載性能。
將部分不影響首頁展示的JavaScript文件延遲到頁面加載后加載；刪除頁面中初始隱藏的區域，改為通過JavaScript按需動態生成；頁面中的部分圖片延遲加載；調整CSS和JavaScript文件的引用順序，即CSS在前JavaScript在后；給靜態文件設置緩存；使用CSS Sprite，合並首頁背景圖；合並和壓縮發布后的CSS和JavaScript代碼文件。
從如上的重構內容可以看到，這次重構的目的是明確的，即提高前端代碼的可維護性和性能。從中也暴露了一些重構過程中的問題：最主要的問題還是低估了重構的風險，導致后續發現了不少新bug；沒有足夠的自動化測試，而貿然去修改代碼，很難保證最終修改代碼的正確性；其次是對於性能優化，事先沒有量化，沒有做任何性能方面的監控，沒有抓住性能主要的瓶頸，所以性能部分的重構就顯得盲目。
有了這次的重構實踐經歷加上學習業內的一些經驗，我歸納了如下的前端重構最佳實踐：
- 重構前一定要預估風險，如果沒有足夠的自動化測試，最好是先完善自動化測試代碼。
- 重構的目的和范圍要明確，切忌盲目修改。前端代碼的重構目的主要是提高代碼的可維護性、可讀性和性能。
- 最好是先易后難，循序漸進。先修改諸如命名、格式等不涉及具體邏輯的內容，然后再考慮模塊化和性能提升等與具體邏輯相關的內容。
- 重構過程中要持續測試，在多個瀏覽器中測試，確保重構的部分功能正確。切忌在大量重構后再進行測試，因為大量重構后基本很難記得重構的邏輯，也就有可能遺漏部分測試用例。
- 如果是性能提升，要事先檢測網站的整體性能並量化，找出性能瓶頸。重構過程中要持續監控性能，並對比性能提升的效果。