前端技術選型及背後思考

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

讀《美團點評金融平臺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： 防跨站腳本攻擊的標準解決方案 同時在覈心接口上使用網頁請求籤名方案，在必定程度上保障請求是從咱們的客戶端中正常發出的。