侯凡-構建可信的大前端工程體系（GOTC深圳會場）（25頁）.pdf

1、大前端新趨勢專場侯凡 2021年08月01日本期議題：構建可信的大前端工程體系個人介紹華為云 CloudBU PAAS服務部CTO辦公室前端技術架構、前端業務交付責任人2010年加入華為參與過多個華為內部工具的前端設計與交付工作目前帶領團隊負責華為云DevCloud、CloudDragon的整體前端業務交付以及前端架構演進與設計工作負責DevCloud、CloudDragon整體產品體驗設計工作前端開源項目DEVUI負責人ECMA TC39成員http:/devui.design侯凡背景1前端技術發展快、更新快交付團隊如何應對技術快速更新帶來的升級風險開源、可靠性、安全、合規產品功能越來越復雜

2、，迭代速度慢體驗要求越來越高，人人都是產品經理產品功能工程越來越大，構建越來越慢業務需求增多，代碼質量工作投入降低開發效率團隊成員多，溝通效率低團隊版本交付節奏不一致，協調難團隊協作背景2大前端工程體系可信構建可信的大前端工程體系 關鍵字大前端是前端領域在廣度和深度的進一步延伸前端體驗服務向前走向前走向里走Desinger&DeveloperSketch to CodeLow/NoCodeBFFNodeJSServerless多端語言框架編譯打包前端工程體系：前端應用越來越復雜，體驗要求越來越高DevOps（Development和Operations的組合詞）是一種重視“軟件開發人員（Dev

3、）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。通過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運維工作必須緊密合作。更小、更頻繁的變更意味著更少的風險讓開發人員更多地控制生產環境更多地以應用程序為中心來理解基礎設施定義簡潔明了的流程盡可能地自動化促成開發與運營的協作提高效率、降低成本DevOps三步工作法流動：建立從左至右快速的、平滑的、能像客戶交付價值的工作流反饋：建立從右到做的，貫穿于整個價值流的快速、頻繁、高質量的反饋信息流持續學習與改進：建立

4、持續學習與改進的文化，持續提升個人技能與產品競爭力9安全性（Security）：產品有良好的抗攻擊能力，保護業務和數據的機密性、完整性和可用性。韌性（Resilience）：系統受攻擊時保持有定義的運行狀態（包括降級），遭遇攻擊后快速恢復并持續演進的能力。隱私性（Privacy）：遵從隱私保護既是法律法規的要求，也是價值觀的體現。用戶應該能夠適當地控制他們的數據的使用方式。信息的使用政策應該是對用戶透明的。用戶應該根據自己的需要來控制何時接收以及是否接收信息。用戶的隱私數據要有完善的保護能力和機制。安全性（Safety）：系統失效導致的危害不存在不可接受的風險，不會傷害自然人生命或危及自然人健

5、康，不管是直接還是通過損害環境或財產間接造成的?？煽啃院涂捎眯裕≧eliability&Availability）：產品能在生命周期內長期保障業務無故障運行，具備快速恢復和自我管理的能力，提供可預期的、一致的服務。Trustworthiness 可信任可追溯 來源可信 E2E 追溯客體的歷史、應用情況或所處位置可度量 要想改進它，就要度量它 研發過程數字化 牽引指標體系可改進 規范與約束 目標牽引 可量化 團隊文化參考度量指標業務含義描述前置時間 Lead Time前置時間是供應鏈管理中的一個術語，也被應用于敏捷與devops中，指用戶提出需求到發布上線的時間。前置時間的縮短除了開發效率外，還

6、要著重審視設計階段的效率需求修改頻次需求修改頻次，可以記錄前端產品需求被修改的次數，從而反應產品經理與設計師在產品設計的規范程度與協作效率需求規范度提交的需求是否滿足約定的規范。比如，復雜特性需要有詳細的高保真標注圖、杜絕一句話需求、杜絕描述不清楚的需求。在收到不滿足規范要求的需求，開發人員有權打回需求，以避免后續的開發成本浪費。而規范度遵循度差的團隊，應該審視相應角色的協作是否存在優化點設計：基于統一的需求規范與設計規范，通過專業工具進行管理，降低溝通成本，提升需求設計效率參考度量指標業務含義描述迭代人均交付需求數在單位迭代內，每個開發人員能完成的人均需求數。由于團隊劃分需求顆粒度習慣是延續

7、的，可能存在個別迭代不同開發人員需求顆粒度不一致的情況，但放在一個較長的時間段內相關誤差基本可控。所以平均迭代交付需求數越高，且呈上升趨勢的團隊，可以理解為團隊交付效率高。迭代人均問題數單位迭代內產生的現網問題數越多，也代表其交付版本質量較差。而如果該指標長期未成收斂趨勢，那么也需要同步審視相應的質量保障體系是否存在優化空間。開發：基于腳手架和統一的開發物料，提升整體開發效率與質量工具或自動化手段：參考度量指標業務含義描述代碼檢查遵從度良好的代碼規范和基礎的靜態檢查能夠避免很多低級問題。而遵從度的指標，要求開發人員必須滿足我們的代碼檢查要求，比如，嚴重問題清零，或者問題100%清零等指標自動化

8、用例覆蓋率開發人員應該編寫對應的測試用例，并基于本次代碼提交的影響范圍，運行相關自動化用例，以確保新功能和歷史功能的質量。尤其對于大型的前端業務系統，必須建立自動化用例體系保障長時間積累的大量特性得到質量保障。在此階段，自動化用例覆蓋率越高，越能保障版本的質量自動化用例成功率用例執行的成功率。頻繁失敗的測試用例，要么反應業務功能的不完善，要么反應測試用例的不嚴謹，從而影響版本質量的驗收，應盡力避免設計：基于統一的需求規范與設計規范，通過專業工具進行管理，降低溝通成本，提升需求設計效率參考度量指標業務含義描述門禁通過率靜態檢查、單元測試、E2E測試、人工驗收測試將會覆蓋到版本的不同環境階段，門禁

9、必須100%通過后，才能流入到生產環境。而門禁通過率代表版本的質量情況構建時長&成功率構建時長：隨著業務代碼不斷年增加，項目深度不斷延伸，構建時長也會不斷增長。關注構建時長的指標，會讓我們關注到版本本身規模增長和代碼健康度是否在合理的范圍內構建成功率：也將表現出當前項目的健康度，規范、高效、本地驗證充足的交付團隊，構建成功率會非常高部署頻率&時長&成功率部署頻率：理想情況下，部署頻率要么保持穩定，要么保持穩定增長，部署頻率的任何突然波動都可能表明現有工作流程中存在瓶頸部署時長：部署時長越短，意味著我們可以更頻繁的進行部署部署成功率：部署失敗率過高，代表我們的版本或運維存在瓶頸設計：基于統一的需

10、求規范與設計規范，通過專業工具進行管理，降低溝通成本，提升需求設計效率參考度量指標業務含義描述MTTR平均修復時間（Mean time to repair，MTTR），是描述產品由故障狀態轉為工作狀態時修理時間的平均值設計：基于統一的需求規范與設計規范，通過專業工具進行管理，降低溝通成本，提升需求設計效率測試右移在線撥測需求設計UI開發開發自檢代碼提交UI門禁編譯構建部署測試功能撥測前端監控版本看板設計稿版本管理設計物料復用設計規范需求規范國際化規范主體化規范前端模板工程CLI套件腳手架組件庫通用前端解決方案Mock API本地tslint/eslint規范本地門禁代碼提交規范代碼檢查codecheckGit hook代碼提及規范門禁靜態檢查門禁流水線引用包檢查配置文件組件庫版本引用非合規資源非法引用檢查組件庫規范掃描標準的構建腳本構建門禁發布包管理（二方包、三方包）發布門禁DI值安全掃描需求完成率標準化部署參數標準文件標準部署方案標準配置方案自動化UI測試用例L0核心功能全量測試灰度測試UI撥測關鍵頁面覆蓋告警Furion監控穩定性性能體驗異常版本可視化看板人力需求交付吞吐質量情況體驗分數早會審視DEVUI前端工程體系度量改進月度前端體驗報告月度前端工程報告做工具的主人THANKS