前端技術選型及背後讀思考

讀《美團點評金融平臺Web前端技術體系》 筆記整理

參考文章：

• 前後端高效協作開發的11條建議

構建技術體系讀基本原則

1. 業務出發

• 選型要針對業務形態特點，注重業務場景匹配度
• 具有一定讀業務前瞻性

2. 團隊出發

• 考慮團隊規模，成員技術特點和偏好
• 考慮現有專案和技術遷移成本

3. 以簡馭繁

主張使用簡單讀技術手段解決複雜讀問題

4. 標準化

儘可能讓上下游銜接形成標準，並在標準下構建質量和效率工具。

例如在元件庫 Vix 的研發上，我們與 UED 形成一致的、強同步的標準，從而大大減少介面搭建的時間消 耗。

5. 自動化

用技術連線技術，用技術簡化步驟，解決工具到使用者讀最後“一公里”問題。
eg： 自動化流程測試，自動化繼承，自動化介面測試

6. 現有複用

選型上儘量使用公司已有的系統和工具，從而更好的與業務、團隊結合。

美團點評金融平臺Web前端技術體系：

前端技術選型涉及到技術單元：

1. 檢視&元件庫

美團點評金融平臺在移動端使用Vue生態，在桌面版使用Vue生態或React生態。

選擇Vue的考慮：

• 體積小，複雜度低
  • 業務上移動端專案佔比 70% 以上，Vue 的體積小，網路效能角度相比 React 更適合移動端
  • 移動端一般巨型專案很少，從程式碼結構上來講，使用 Vue 實現更符合我們的場景複雜度， React 更適合大型相對更複雜的 SPA
• 上手成本和遷移成本低
  • Vue 的學習和上手成本相對更低，團隊成員對於 Vue 的認可度和熱情也比較高
• 元件內雙向繫結、資料依賴收集
  • 元件內支援雙向繫結，更方便的去進行元件內的資料響應與互動
  • 獨有的資料依賴收集模式使其預設的資料響應和渲染效率都要比 React 高一些

React的使用主要考慮一下原因：

• 有一部分現有後臺專案採用 React 技術棧，迭代和維護較少，老的專案如果沒有足夠的遷移價值則不額外投入資源
• 保留很小的一部分 React 技術生態也可以一定程度上保持一些技術多樣性

2. 元件庫

元件庫的選擇是前端技術棧選型的一個重要部分，直接影響到研發效率、軟體質量、以及互動體驗。

元件庫可劃分為基礎元件、複雜元件、業務元件。

PC端內部系統研發的4個特點：

• 無產品，要求高：幾乎沒有產品經理跟進，以完成功能需求為主，但功能流程一定要完善，最好能支援手機端使用
• 無設計：幾乎沒有設計跟進，面對內部使用者設計收益不高
• 無測試：幾乎沒有測試跟進，收益不高，功能驗證通過即可
• 要快：大多數是配合使用者端產品的管理系統迭代，也可能是新系統的搭建，對研發速度都有要求，往往這方面的估時較短

因此，在內部系統的研發上有四點要求：

• 元件設計合理，元件數量大而全，最好支援移動端使用
• 元件庫本身要有不錯的設計，使用者量雖少，但活躍度超高，介面體驗需要保障
• 元件庫本身的質量要高，要從工具層面保障質量減少出錯
• 元件庫要能夠快速拼裝出功能

3. 語言

強型別語言的作用：

• 在開發期間或編譯期間進行強型別檢查
• 使用型別系統讓程式碼可控性、擴充套件性更強，協作更方便
• 避免 something is undefined 的空指標問題

語言選擇：

1. Typescript, 微軟出品
2. Flow， Facebook出品

選擇 TypeScript 是因為以下幾點：

• RoadMap 清晰，方向以貼合 ECMAScript 為核心，在其之上構建型別系統，傳言 ES8 也會增加型別系統
• TypeScript 是 JavaScript的超集，其作用只在開發階段發揮，其生成的程式碼不包含任何型別程式碼，但由型別系統保障
• IDE 支援極好，除了自家的 VSCode 整合度超高，使用者增長飛速，TypeScript 還支援市面上幾乎所有主流 IDE
• 社群龐大，周邊工具豐富
• 當時已經有幾個大型的開源專案在使用，例如 Angular 和 Express
• 研發團隊活力和積極性都很高，很多開源生態均快速推進整合

TypeScript 包括 型別守護、聯合型別、型別推導、嚴格非空檢查等功能。

使用Lint 工具保障程式碼風格和質量。

4. 協作解耦

協作解耦就是讓前後端的開發工作不互相依賴，從而優化研發效率。

工具推薦：

• RAP是一個視覺化介面管理工具 通過分析介面結構，動態生成模擬資料，校驗真實介面正確性， 圍繞介面定義，通過一系列自動化工具提升我們的協作效率。

前端與後端協作提升開發效率的一個很重要的方法就是減少溝通：能夠形成紙質的文件就不要口頭溝通、能夠把介面文件寫清楚也不要口頭溝通（引數、資料結構、欄位含義等）。

5. 自動化測試

6. 使用者體驗

7. 離線化技術

• Application Cache：實現上各個平臺各個瀏覽器有一些差異，即使把“無法更新的坑”踩過還是會有很多“無法離線”的坑，PASS

• Service Workers：Service Workers 是團隊一直跟進的技術，目前在測試已經接近正式釋出，只是在 iOS 上還 無法大範圍使用，長期看好，暫時 PASS

離線載入技術要考慮以下問題：

• 是否解決了首次載入問題？
• 離線化方案的首次載入問題是一個很難的技術領域，我認為其最核心的問題是何時載入，提前載入會不會使用者在很長一段時間內都不會用到導致浪費流量？
• 使用包含首次載入優化的離線化技術的專案多了會不會造成載入擁塞？
• 是不是需要分析使用者行為資料去更精準的進行離線包的提前載入？

8. 增量更新方案

9. 監控日誌系統

異常監控、效能監控、網路監控

10. 安全方面

安全方面在前端我們使用：

• HSTS： 防 SSLStrip 攻擊的標準解決方案
• CSP： 防跨站指令碼攻擊的標準解決方案 同時在核心介面上使用網頁請求籤名方案，在一定程度上保障請求是從我們的客戶端中正常發出的。