--58安居客北京前端團(tuán)隊(duì)《巧寓sass系統(tǒng)》開發(fā)紀(jì)實(shí)

前言

如標(biāo)題所講，本文將要記錄的是我在真實(shí)的項(xiàng)目開發(fā)過(guò)程中，如何將一個(gè)2017年代碼的JQ項(xiàng)目一步步遷移升級(jí)為react + 微前端技術(shù)架構(gòu)的。這個(gè)過(guò)程中，我們又經(jīng)歷了什么呢？踩過(guò)哪些坑呢？

項(xiàng)目介紹（站在巨人的肩膀上吐槽）

這是一個(gè)面向經(jīng)紀(jì)公司的sass系統(tǒng)，有PMS（經(jīng)紀(jì)人使用）和CMS（運(yùn)營(yíng)后臺(tái)使用）兩套系統(tǒng)，其在業(yè)務(wù)中的重要程度，不言而喻，本文不做過(guò)多的業(yè)務(wù)介紹，我們把側(cè)重點(diǎn)放在技術(shù)上。

原項(xiàng)目技術(shù)介紹

首先，這是一個(gè)jq + vue技術(shù)棧的項(xiàng)目，下面看一下原項(xiàng)目部分代碼截圖

看著這個(gè)用日期版本號(hào)，我猜測(cè)，這是一個(gè)17年甚至更早的項(xiàng)目，考慮到項(xiàng)目的體量，大概是在16年底的項(xiàng)目吧，那時(shí)候jquery確實(shí)是撐起來(lái)前端的一片天，不過(guò)也是在那個(gè)時(shí)候，前端技術(shù)圈正悄然著發(fā)生著翻天覆地的變化，ES6正在推廣普及，三大框架競(jìng)爭(zhēng)激烈，webpack也悄然改變著前端工程化的面貌，babel的強(qiáng)大功能，也正在悄悄的滲透到前端的各個(gè)方面...
正當(dāng)我為項(xiàng)目中有引入vue而慶幸時(shí)，接下里的一幕，卻又直接讓我流淚。

也就是說(shuō)，如果有的頁(yè)面用到了vue，其用法就像是做demo一樣的，在html文件中引入vue.js然后像上面截圖那樣去掛載實(shí)例等等...當(dāng)然，這也理解，因?yàn)樵趈q的大環(huán)境下（無(wú)編譯壓縮工具），vue也不可能做成單頁(yè)面應(yīng)用這一類。我想可能這個(gè)項(xiàng)目就處在了當(dāng)年前端技術(shù)變革的初期吧，開發(fā)者也是盡可能的想要去嘗試新鮮的技術(shù)。

再來(lái)看看項(xiàng)目架構(gòu)，從表現(xiàn)上，整體的架構(gòu)更像是一個(gè)SPA項(xiàng)目：有些統(tǒng)一固定不隨頁(yè)面刷新的布局，通過(guò)indel.html訪問項(xiàng)目...，但其實(shí)現(xiàn)原理其實(shí)是這樣的

• jquery已經(jīng)成為歷史，在現(xiàn)在的大環(huán)境下，開發(fā)者對(duì)于jquery的使用明顯的低效且bug率高
• iframe相互嵌套的代碼復(fù)用方式，對(duì)于邏輯的抽離和封裝并不是一個(gè)友好的方式，經(jīng)常會(huì)牽一發(fā)動(dòng)全身，有時(shí)候不知道這個(gè)頁(yè)面被多少頁(yè)面所嵌套和處理。
• 現(xiàn)有的”偽SPA“模式，無(wú)法通過(guò)指定的url跳轉(zhuǎn)到對(duì)應(yīng)頁(yè)面，原因就是上面截圖那樣的，重新加載index.html，只能到其初始化時(shí)的iframe頁(yè)面。
• 無(wú)前端工程化，編譯、打包、熱更新等概念...開發(fā)和部署起來(lái)十分難受
• 本地開發(fā)需依賴node或python服務(wù)，環(huán)境比較復(fù)雜
• 業(yè)務(wù)體量大，服務(wù)拆分不易，無(wú)法實(shí)現(xiàn)微前端等前沿技術(shù)
• 開發(fā)人員一直在老代碼中沒有技術(shù)成長(zhǎng)
• ...

面對(duì)這諸多的原因，于是，我想，那做一個(gè)升級(jí)吧...

技術(shù)升級(jí)

如此大的項(xiàng)目，一次性重構(gòu)必然是不可能的。這需要一步步的探索，一點(diǎn)點(diǎn)的蠶食，才能一步步踏入正軌。

第一步：接入正常的SPA項(xiàng)目

通過(guò)上面分析，原有架構(gòu)，在這個(gè)時(shí)代下存在著很大的問題，如果要升級(jí)，在原有的技術(shù)上迭代升級(jí)，幾乎是不可行的，那么首先就要先脫離原先的技術(shù)，創(chuàng)建一個(gè)工程化的、技術(shù)新的、正常的SPA項(xiàng)目。
新項(xiàng)目采用技術(shù)棧 react + antd + umi，第一個(gè)擺在我們面前的就是新老項(xiàng)目如何通信，首先要想接入老的技術(shù)架構(gòu)，還是得讓我們新的SPA項(xiàng)目，成為老架構(gòu)中上百html中的一個(gè)。這里就需要了解SPA的特點(diǎn)了

• 只有一個(gè)html
• 打包編譯后的JS和CSS（無(wú)關(guān)是否分包處理）當(dāng)做靜態(tài)資源
• 因?yàn)镾PA路由的存在，我們可以在SPA的index.html中通過(guò)指定url訪問對(duì)應(yīng)頁(yè)面

既然SPA被當(dāng)成了其中一個(gè)html,且通過(guò)URL訪問對(duì)應(yīng)頁(yè)面，那么按照原有架構(gòu)，我們也可以通過(guò)URL傳參的形式完成新老項(xiàng)目的數(shù)據(jù)通信了，實(shí)際上，原iframe架構(gòu)中，所有的頁(yè)面之間的通信都是通過(guò)url傳參完成的，我們這樣也算是繼承了原有架構(gòu)的特點(diǎn)。

第二步：SPA嵌入舊項(xiàng)目

通過(guò)第一步的操作后，其實(shí)是可以實(shí)現(xiàn)大部分完整的新需求的，但對(duì)于不太完整的重構(gòu)需求來(lái)講，就會(huì)存在互相嵌套的過(guò)程，這也是當(dāng)初解決的其中一個(gè)問題點(diǎn)所在，因?yàn)樵?xiàng)目中，有好多iframe互相操作的代碼，比如下面這樣的代碼：

第三步：面對(duì)弊端

我們通過(guò)上面的兩步，基本可以滿足所有的業(yè)務(wù)需求了，但隨之而來(lái)，帶來(lái)了交互上的一些弊端，因?yàn)槭莾蓚€(gè)獨(dú)立的項(xiàng)目，而新項(xiàng)目又為了保持環(huán)境的簡(jiǎn)潔沒有引入太多復(fù)雜的東西，比如postmessage，所以，有一個(gè)問題就是，兩個(gè)想之間的方法調(diào)用問題，這是目前無(wú)法解決的，但是對(duì)于獨(dú)立模塊的重構(gòu)，都是沒有問題的，對(duì)于新舊項(xiàng)目的混合，存在的交互問題，這里就只能讓我們的產(chǎn)品同學(xué)暫且妥協(xié)，等提出完整的需求可以將舊項(xiàng)目和老項(xiàng)目不嵌套后，那么我們的問題也就解決了。

第四步：微前端

通過(guò)上面一點(diǎn)點(diǎn)的對(duì)舊項(xiàng)目的“蠶食”以及時(shí)間的沉淀，我們的新需求已經(jīng)都可以順利的接入SPA項(xiàng)目了，并且已經(jīng)有幾個(gè)完整獨(dú)立的模塊完全脫離的老的架構(gòu)，順著需求的增多，SPA的弊端也就暴露出來(lái)了，如首頁(yè)加載慢等，因?yàn)槲覀兊腟PA都是通過(guò)iframe的形式嵌入到老系統(tǒng)中的，終歸還是一個(gè)html，那么新開一個(gè)或者多個(gè)SPA已成必然，這也正是微前端的落地時(shí)機(jī)，我們將打算采用qiankun來(lái)做微前端的改造。

寫在后面

到現(xiàn)在為止，隨著時(shí)間和技術(shù)的沉淀，《巧寓Sass系統(tǒng)》已經(jīng)步入了一個(gè)開發(fā)正規(guī)，我們不斷的在尋找機(jī)會(huì)，解決問題，每到達(dá)一個(gè)時(shí)機(jī)，我們的項(xiàng)目升級(jí)就會(huì)進(jìn)一步，相信不久的以后，本項(xiàng)目全部會(huì)被新技術(shù)替代。

總結(jié)一下：在開發(fā)中我們會(huì)面對(duì)各種棘手的問題，要善于思考，多多嘗試，當(dāng)解決方案出現(xiàn)在眼前時(shí)，那一刻是多么的有成就感。并且自己也會(huì)在這個(gè)探索的過(guò)程中，有很大的收獲。