### 引言

對於一個工程師而言，不僅要有過硬的自身本領，還要有一定的技術影響力。當我們解決一個問題之後，如何在團隊中順利的推廣並落地，也同樣重要。接下來，想給大家分享一下，我在團隊中推廣一項技術解決方案的全過程。

### 問題的出現

年前的時候，我們團隊對 [Odin一站式](http://odin.xiaojukeji.com/) 的**微前端**方案進行了改造和升級。最早是透過 `iframe` 來完成這一方案的。

iframe 作為一個非常 “古老” 的，人人都覺得普通的技術，卻一直很管用。它能有效地將另一個網頁/單頁面應用嵌入到當前頁面中，兩個頁面間的 CSS 和 JavaScript 是相互隔離的——除去 iframe 父子通訊部分的程式碼，它們之間的程式碼是完全不相互干擾的。iframe 便相當於是建立了一個全新的獨立的宿主環境，類似於沙箱隔離，它意味著前端應用之間可以相互獨立執行。

但是 iframe 不夠靈活。它會使路由、歷史記錄和深層連結變得更加複雜，並且很難做成響應式頁面。

於是，團隊決定使用 `Web Components` 的方案來替代 iframe。

Web Components 是一套不同的技術，允許開發者建立可重用的定製元素（它們的功能封裝在程式碼之外），並且在 web 應用中使用它們。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_5GEBaCJbfKEhnkNXUBui)

我們上線這一方案之後遇到一個問題：使用者重新整理瀏覽器之後沒有看到系統的更新。由於我們註冊子服務時，使用的是一個不帶雜湊 `js` 檔案來註冊的。而代理層對於這部分靜態資源的快取策略是會快取下來的。這種死檔名的方式就使得快取的問題重新暴露了出來，使用者使用我們的系統時，需要強制重新整理或者不使用快取，才能看到系統更新的內容。

當然，也可以讓接入層設定不快取所有檔案。但是這樣的話每次都需要請求所有檔案，十分影響效能。而且需要頻繁修改Nginx的配置，會增加跨部門協作的成本。可能就將一個簡單的問題複雜化了。

### 獲得靈感

本著 **“我一定不是第一個遇到這個問題的人”** 的思想，一個技術問題一般會有如下的解決方案：

- 1、google 搜尋
- 2、當一個伸手黨
- 3、開源社群提問
- 4、探究原理，明白到底發生了什麼
- 5、看原始碼，嘗試自己解決

其實，前3個方式都是提問，只是方式不同罷了。但是如果可以問對人，那麼一定是最快的方式。

而我這次可以解決這個技術難題，也源自我參加了2020年1月11日Node party線下分享。阿里的流司分享的主題，就是[《⾯向B端⼯作臺的微前端⽅案-ConsoleOS》](https://github.com/aliyun/alibabacloud-console-os)。在分享結束的時候，我向他提出了我的疑問。他們的方案中是使用 `manifest` 來解決一個入口，多個檔案的問題的。`manifest.json` 中，可以儲存子系統多版本的所有資原始檔。這樣的話，只需要寫死一個入口，裡面的資原始檔就可以加上雜湊字尾，從而解決這一問題。

### 解決問題

第二天，我就衝到公司，對主系統和子系統進行了改造。折騰了一天之後，就完成了這個方案的第一版：使用 `manifest.json` 作為入口檔案，載入子系統。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_V4W5LLVsea5qyUGnKpYM)

在推行這個方案的時候，起初是沒有被採納的。原因如下：

- 演示不夠具有說服力。Demo 中只能演示上圖的載入過程，並沒有完整的演示快取問題的解決。
- 跨部門協作成本較大。接入層的快取策略一般是不快取 `index.html` ，`manifest.json`也是會快取的，這個方案需要接入層調整代理配置，代價較大。
- 方案不具備通用性。每一個子系統在打包的時候，命令和配置不是完全一樣的。這個方案不一定適用於每個子系統。
- 風險不可控。方案中沒有考慮到測試，到上線各個階段的注意點。訪問的鏈路增加，是否會影響效能？子系統釋出之後，是否會影響到一站式，和老系統的使用？
- 沒有通俗易懂的文件。

### 讓你方案變得可靠

工程師的真正價值就是把未知變成已知的能力。但是一個想法從知道，到實際落地，還是存在一定距離的。

- 1、探究原理。在這個過程中，我做的第一件事，還是去了解這個問題發生的根本原因，瞭解 [HTTP 快取](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ) 的原理。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_qCBbJqdxr7gz8zj9x5RJ)

- 2、降低跨部門協作成本。在明白原理並與後端同學溝通之後，明白接入層不會快取 `index.html` 這個高頻更新的檔案，於是就最佳化了鏈路。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_EJdAVxuVs1kCseBT22zr)

- 3、讓方案變得通用。接下來，就需要明確各個系統的接入層快取配置，並且對幾個典型的系統進行改造，發到測試環境。
- 4、讓方案可以相容各個階段。上線的時候，所有系統的更新會有先有後。在打包子系統的時候，不僅會生成新系統需要的 `manifest.json`，還會生成老版本一站式所需要的 `entry.js` 檔案。讓整個升級變得更加平滑，不會出現系統不可用的情況。
- 5、健全的文件。梳理子系統的改造過程，將子系統改造的每個步驟寫清楚，以及遇到各種情況的處理方案。

這次，方案終於透過，可以進入實際改造的環節。?

### 積極地幫助他人

在這裡，容我先放一張沙雕圖..

![img](http://cooper.didichuxing.com/reads3/shimo-images/kUjVJaTwLA04w305/image.png)

不同的人，對於同一個方案的理解，有時候可能會有些差異。而且，其實我在整理方案的時候，並沒有考慮到所有情況。

![img](http://cooper.didichuxing.com/reads3/shimo-images/I88gaLngnfYE4LWw/image.png)

這個時候，就需要扮演好客服，以及售後的角色了。第一時間幫助同事解決出現的各種情況。

### 總結

跌跌撞撞一個月，在小夥伴的協助下，這個方案最終還是上線了。[體驗地址：Odin](http://odin.v5.intra.xiaojukeji.com/) 。

之前有看張鐵蕾老師的文章[《技術攻關：從零到精通》](https://mp.weixin.qq.com/s/mix-0Ft9G1F5yddNjSzkrw)，文中講到如何解決一個從來沒接觸過的任務：

- 研究問題本身：先研究問題本身是怎麼產生的
- 對專業領域的Overview：花最短的時間快速瞭解相關的各個概念
- Run起來，獲得感性認識
- 同行交流：能夠Run起一個實現，並從API層面粗略地瞭解一項技術之後，在這個認識的基礎上，我們就差不多可以找同行交流一下了。
- 研究Spec：所謂Spec，是集中體現該項技術的設計思想的東西，是高度抽象的描述，一般也是一份完備的、系統性的描述。
- 研究和選擇具體實現
- 研究相似產品的實現
- 網上瀏覽最佳實踐
- 結合自己的系統設計方案
- 系統實現的過程

到這裡，問題應該已經得到了解決。但是真正要推廣開來，還需要：

- 溝通，聽取他人意見。去了解當前方案需要哪些人的協助，舉辦評審會，收集、聽取他人的建議。
- 確定影響範圍，增強方案的相容性。
- 通俗易懂，經得起反覆推敲的**文件**。

如果可以做到這些，相信難題也可以迎刃而解了~

##作者：張博軒【滴滴出行高階軟體開發工程師】

嘀～滴滴雲618來啦！年中巨惠，錯過今天，再等半年！
滴滴雲使者專屬特惠，包年雲伺服器低至68元／年
[![](http://img.blog.itpub.net/blog/2020/06/10/955c1226cb53e4a1.png?x-oss-process=style/bb)](https://www.didiyun.com/?channel=14816)
[![](http://img.blog.itpub.net/blog/2020/06/10/2789d0c05210236a.png?x-oss-process=style/bb)](https://www.didiyun.com/?channel=14816)

如何在團隊中推廣一項技術 —— 解決Odin一站式微前端的快取問題

相關文章