Front-End Practice 2019

https://medium.com/@evenchange4/front-end-practice-2019-251a5876a6c8

Transcript

1. Front-End Practice Nov, 2019 Michael Hsu
2. ⽬標 1. 明年邁入 2020 是公司前端團隊第六週年，整理 2019 年度 Front-End 的實踐與技術盤點 2. 對於前端團隊⽽⾔，什麼才是該關注的⾯向，梳理了現 況開發模式、過去回顧及未來的關注 3. 期望也能給予往後成員⼀些 Guideline ⽅向可以遵循 重要指標：✅ 效率效能 ✅ 穩定性 ✅ 擴展性 ✅ 前瞻性
3. Roadmaps for Front-end Developers • 檢視⾃我能⼒所缺乏之處 • 明確知道前端的職責範圍 1 2 3 4 5 6 7
4. 1. Client-Side Frameworks (1/2) 公司內使⽤了 Angular ⼀年與 React 五年，考慮⽤ Vue 或 其他關鍵字技術？ • 已經能夠在數個專案的磨合下，⼤幅度的滿⾜團隊需求 • 問題之上應該要釐清的是 Why React.js community • Facebook：⼤公司的背書、⽣態圈、社群的活絡 • ❌ 不看彼此語法之間的差異
5. 1. Client-Side Frameworks (2/2) 採⽤⼀個技術時，不只是比較 API 的封裝，我們挑選能改 變開發思維 ✅ 前瞻性 • Declarative and Reactive Programing、Data Flow、 Immutability 的設計理念、到近年 Functional Programing、 UI Component 模組化 ✅ 擴展性 ⽬的降低專案維護上的困難、增加開發可預期性、使測試 更為⽅便，以提升專案健康度。✅ 穩定性
6. 2. Zero Configuration Setup (1/2) 前端領域最為困難的是開發⼯具，理解現代⼯具 Webpack 的 發展是有必要的，但每當開始新專案⼜得再次堆起積⽊： • ❌ 前置作業花費瑣碎的時間 → 因此有了⽣成專案的⼯具， 不⼤需要額外的設定 Zero Configuration Frameworks • 保有客製化的空間 ✅ 擴展性 • ⼤幅減⼩專案啟動的最⼤靜摩擦⼒ ✅ 效率 • 讓維運成本轉嫁，以專注於產能提升 ✅ 效率 ✅ 穩定性
7. 2. Zero Configuration Setup (2/2) • ⾯對不同性質的網站需求，且當專案規模不明確時，以上三 個成熟 Zero Configuration Frameworks。 • Next.js 相較能夠滿⾜各類專案，為彈性的解決⽅案 ✅ 擴展性 SPA (Single Page Application) SEO Dynamic SSR (Server Side Render) Extensible Create React App (Official) Eject Gatsby.js O (Pre-rendered HTML) O (Plugins) Next.js O (Static Exporting) O O (Plugins)
8. 3. UI Modularize (1/3) 採⽤ React 使得 UI 元件模組化成為顯學，就⼀個專案的 開發週期來說 1. 定義元件 2. 各個⾴⾯挑選元件進⾏組裝 3. 複雜的元件可以將數個元件 Compose ✅ 擴展性 4. 甚⾄是跨專案能夠複⽤ ✅ 效率
9. 3. UI Modularize (2/3) 過去 MCS-UI 是以⼀個團隊標準化作為⽬ 標，搭建符合 Branding 的 Guideline： • Open source UI Framework： Material-UI ✅ 效率 • 規劃完整的設計框架，其元件種類豐富、 ⽂檔⿑全、API Spec 的擴充性 ✅ 穩定性 • ⽤以提升開發體驗的 Styled System 設計 ✅ 擴展性 • 使⽤後也能從中學習到⼀些技巧 ✅ 前瞻性
10. 3. UI Modularize (3/3) 談論模組化，除了 CSS，邏輯上的封裝也是⼀種設計美學 • React：Higher-Order Components (HOC) → Render props → Hooks 解決了模組化的痛點 ✅ 效率效能 • 讓測試更專注，模組化複⽤思維的改變引領各⼤社群的 相繼參照與討論 ✅ 前瞻性
11. –延伸閱讀 [Apr, 2017] Build A Web App in MediaTek [Apr, 2017] Refactoring React Component in Reactive Way
12. 4. API Communication and Data Layer (1/2) 提到前後端分離 • 最重要的是雙邊的溝通，GraphQL 成為最佳的橋樑 • 整體網站效能的提升 ✅ 效能 • 有著開發完即完成⽂檔的特性 ✅ 穩定性 • 因此當開發⼀套系統時，前後端可以先協商 GraphQL Schema Definition Language (SDL)，⼀旦定下了 Spec 將 ⼤幅減去溝通成本。 ✅ 效率 ✅ 擴展性
13. 4. API Communication and Data Layer (2/2) Side Effects 與狀態的管理是前端的課題之⼀，過去 RESTful 與 Redux 是提出的主流解決⽅案，⽽今 Apollo Client 搭著 GraphQL 出現： • Cache 設計上讓很多瑣碎的事情⾃動化 ✅ 效率 • 聲明式的數據取⽤，⼤幅降低前端專案 Codebase 的複雜度 ✅ 穩定 性，使狀態的管理更為直覺 ✅ 效率 未來，此難題由 Facebook 提出從根本設計上去改善，因⽽ React Concurrent Mode 的出現，將提升 Side Effect 的微控能⼒，勢必會 再次帶動使⽤者體驗上的優化，是未來可以密切關注的項⽬。✅ 前瞻 性 ✅ 效能
14. –延伸閱讀 [Dec, 2017] GraphQL — JavaScript Fullstack Solution [Aug, 2017] GraphQL Microservice with Apollo [Jul, 2017] Centralized Error Handle in React with RxJS
15. 5. Code Quality and Performance (1/3) ⼯具標準化是⼀個團隊健康度的表現： ✅ 穩定性 ✅ 效率 1. Prettier: Coding Style 排版 2. ESLint Rules: 開發語法基礎、語意細節不遺漏 3. Static Type Check: 多⼈合作不可或缺，採⽤ TypeScript 補⾜ 了 JavaScript 型別語法上的不⾜ • 另外，也可以採⽤諸如 GraphQL Code Generator 的⼯具，⾃ 動化產⽣ Type 語法，盡量減少撰寫瑣碎的程式碼。✅ 效率
16. 5. Code Quality and Performance (2/3) 模組化，其⽬的之⼀為讓測試更為專注 Jest： • ❌ Enzyme → React Testing Library 不要過度理解實作細 節，從 User Story 在意的操作⾏為進⾏測試 ✅ 穩定性 • ❌ 不需要達到 100% Test Coverage rate，尤其時在 Scrum 快速迭代下，過多的測試反成累贅，⽬前經驗⼤ 概介於 70% 左右。✅ 效率
17. 5. Code Quality and Performance (3/3) 評估網站，因應瀏覽器的更新，效能指標需與時俱進，最 好的做法是查看社群整理的⼤抄： • HEAD • Front-End Checklist ✅ 效率 • Front-End Performance Checklist ✅ 效能 為產品交付前可以參考的清單
18. –延伸閱讀 [Jul, 2017] React Stack 開發體驗與優化策略 [Apr, 2017] Introducing Prettier with Eslint [May, 2017] Component-based Code Splitting [May, 2017] 這個雷踩了四次，為什麼你可能需要 Eslint [May, 2017] Reproducing Medium Style Progressive Image Loading for React
19. 6. CICD Workflow and Production (1/2) • ⼯作流程可以從不同⾓度切入 • Scrum 管理⼯具 Jira 在看板的設計
20. 6. CICD Workflow and Production (2/2) CI Server Docker-based 的基礎：Drone • 乾淨的執⾏環境 ✅ 穩定性 • ❌ Bamboo → Workflow as Code 的⽅式來管理專案 ✅ 穩定性 容器化 ✅ 穩定性 • pkg: 打包為 Binary，提供跨平台⽀援 • Docker Compose / Kubernetes：DevOps Roadmap ✅ 擴展性 • Infrastructure as Code (IaC)：機器管理與維運 ✅ 前瞻性
21. –延伸閱讀 [May, 2018] Deploy a commercial Next.js application with pkg and docker [May, 2018] Make Your React Service Portable [Sep, 2017] 五分鐘 Kubernetes 有感 [Aug, 2017] Microservice 產品交付 [Jul, 2017] 使⽤ CircleCI 2.0 Workflows 挑戰三倍速 [Apr, 2017] I18n Workflow for React Project
22. 7. Beyond Front-End (1/2) • 洽接數個現有系統 • Backend-For-Frontend (BFF) • 都是⽤ JavaScript 做開發 ✅ 效率效能 ✅ 擴展性
23. 7. Beyond Front-End (2/2) 在 TensorFlow.js 的 發展下，能使⽤瀏 覽器資源進⾏深度 學習，即時的推論 與預測 ✅ 前瞻性
24. –延伸閱讀 [Sep, 2019] Inference on the Browser with Tensorflow JS [Dec, 2017] GraphQL 漸進式導入的架構
25. ✅ 效率效能 ✅ 穩定性 ✅ 擴展性 ✅ 前瞻性 1. Client-Side Frameworks O O O 2. Zero Configuration Setup O O O 3. UI Modularize O O O O 4. API Communication and Data Layer O O O O 5. Code Quality and Performance O O 6. CICD Workflow and Production O O O 7. Beyond Front- End O O O
26. 團隊開發模式為什麼會發⽣迭代 1. 硬體與瀏覽器的進步與安全性的加強，驅動了技術的變化 • 完善的開發⼯具，已經盡量彌平過渡期所造成的差異 2. ⼈的因素 • 團隊成員的流動與組成，是決定⼀個團隊技術棧的關鍵 • 適應追逐新技術的環境，不變的是過程中所累積的經驗 與開發思維。
27. Conclusion & Takeaways 1. ✅ 選擇⼀⾨技術，是否對於思維上有所改變 2. ✅ 維運成本轉嫁，專注於產能提升 3. ✅ UI 模組化成為了顯學 4. ✅ GraphQL 的採⽤成為專案的⾸選 5. ✅ 從 User Story ⾏為進⾏測試，不過度理解實作細節 6. 斜槓前端，具備統整能⼒
28. Q&A Thanks! 1 2 3 4 5 6 7