騰訊 Web 前端大會分享淺析 -- 主會場篇

時間 2019-11-16

標籤騰訊 web 前端大會分享淺析會場欄目騰訊简体版

原文原文鏈接

騰訊 Web 前端大會完美落幕。但願你們能收穫滿滿乾貨。博主負責大會部份的講師的遴選。雖然我全程都沒怎麼聽（基本都在安排展位和發微博），但我但願經過選題的角度，以及PPT的內容，給你們分享一點思路和分享的導讀。css

TC39, ECMAScript, and the Future of JavaScript

第一位講師是在 Elastic Search 工做的 Nicolas Bevacqua，他同時也是知名書做者和博主。html

他所分享的這個主題，是跟W3C的標準制定相關。對於大神們說，這個知識都已經有所涉獵，但對於新入行幾年的新人來講，可能相對陌生。Nicolas 出了與 ES6 有關的書籍，是這方面的專家，所以邀請他過來分享很是合適，也考慮到他是作英文分享，所以經過分享W3C標準制定流程、W3C標準的新特性這類知識性的分享，不會太艱澀難懂，但又對引發國內對W3C關注也起到必定的效果。畢竟國人在技術上，太過關注業務，大會仍是但願經過引發你們對「標準」的關注，讓愈來愈多的國人能花時間精力投身到「標準」的制定上去，比方說騰訊前端第一人「黃老師」 Stone Huang 就是W3C中國信息無障礙社區組的主席。前端

本分享主要介紹的有，TC39是什麼，以及他們制定規範的流程是怎麼樣的。關於這方面，我曾經閱讀過一篇不錯的介紹性文章《JavaScript(ECMAScript) 語言標準歷史及標準制定過程介紹》，我就再也不贅述了。Nicolas 在分享的時候，只點到了TC39是制定標準的委員會，不過沒提到的是其實每一個開發者都有機會成爲一份子。另外，從Stage 0 到 Stage 4，整個標準制定過程從提案、審閱、算法規劃、Polyfill到測試用例，這一切保證了整個流程的更加快速可靠。讓W3C標準在這兩年的進展一會兒加快了很多。Nicolas 還提供了比較有趣的故事就是，以前W3C都是用着老舊的Microsoft Word來建設文檔，是後來使用了Github以後，讓整個流程更公開快捷，因爲扭轉了W3C標準指定落伍的局面。Nicolas 本身還專門建了個網站，用來監察 W3C 標準制定的進展。TC39 proposals。java

我以爲最須要理解W3C的時候，是使用 Babel 的時候。由於 Babel 會經過不一樣的 preset 或者 plugin 幫你去編譯不一樣的新特性。node

Babel 的 plugin 經過只支持某一種特性的編譯，而 preset 則是指一系列的 plugins 。所以咱們常見到 es2015, es2016 這些 preset，而偶爾會見到 transform-decorators-legacy 這一類 plugin。一般來講，進入 stage4 的特性基本篤定能進入標準當中，通常能夠經過 Babel 放心使用（不過不排除會有性能的問題），但以前的 stage，隨時有可能回爐重作，所以要慎重使用。webpack

分享最後稍微介紹了一些現代的前端工具，git

npm，Javascript 包管理工具，戰勝了 bower
webpack，JavaScript 打包工具，擊敗了 gulp，require.js
babel，JavaScript 編譯工具
rollup，新一代 JavaScript 的打包工具，在類庫開發中頗受歡迎
eslint，JavaScript 代碼質量檢查工具
prettier，JavaScript 新一代代碼質量檢查工具，大有取代eslint之勢
node，JavaScript V8 運行環境程序員

初始公司前端工程體系建設

本分享有幸邀請到的是前端業內工程化的大神張雲龍，以前是FIS的核心開發者，目前在全民主播擔任CTO。辦大會的時候，一直就想着要在主會場安排一場工程化的分享，必定要請張雲龍過來分享，沒想到願望達成（擦當天太忙還沒空跟他合照！！！）。github

我一直是想推進業內前端工程化的，讓全部程序員都由於工程化讓性能優化、持續集成、測試部署、發佈監控更爲駕輕就熟。我看到的反面教材是當今國內的電影業，拍攝太過隨意，徹底不講流程，前期拍很差就由後期來擦屁股（詳參《《擇天記》收官在即，「5毛特效」背後的故事你不能不知道》）。但反觀國外，電影已是一項成熟工業了，「工程化」作得很好，各方面都控制得至關規範，所以即便咱們有時候以爲情節方面有缺陷，但整體來講能達到所謂的6分「工業水準」，不至於強差人意，偶爾情節不錯，也能來個8分9分的爆款。而國內電影因爲「工程化」缺失，3分4分的腦殘片、5毛特效片比比皆是。從國產電影這個反面教材，我深知若是讓國內的頁面水平也能保持至關好的工業水準，工程化是繞不開的一道檻。

雲龍大神選的這個題仍是蠻有實用價值的，畢竟在大公司工做的人是少數，很多開發者仍是在中小企業裏工做的，沒有專門的人負責幫你搭建好全部的工具。所以，雲龍大神選的這個「初創公司」的切入點，不只直接與他當前工做的經驗相關聯，也能引發在座許多開發者的共鳴。

分享開篇就先點出了講者自身所處的業務環境與團隊規模，業務複雜，但團隊不大，所以得出來但願工程化提升效率的同時，卻面臨很多現實問題的尷尬局面。

而後做者開始直接拋出解決問題的方案。我先把總結放上來：

前端架構：組件開發 + 子系統拆分
持續集成：基於 Gitlab-CI 環境及 GitFlow 開發規範
系統測試：基於 Dom-Diff 的自動迴歸檢查系統。
敏捷開發：物理看板

前端架構：組件開發 + 子系統拆分

這裏提到的與架構相關的是組件化開發，同時點出其背後的核心概念，即「分治」。這部份提到一個有意思的點，即是服務端模板裏也用到了組件化的方式。以下圖，經過資源表來管理靜態資源，require 引入 js/css， widget 引入組件（多是html加上js/css?）。這是以往不用Node開發後臺的方式。而以如今咱們常見的 Node + Webpack + React，則是直接在服務器運行JavaScript 生成 HTML 字串再吐出來。有點惋惜是的可能因爲篇幅和時間關係，具體技術細節並無展開，仍是很但願能夠對比一下兩種方式在SEO、維護效率、性能（QPS每秒查詢率）等方面一些數據的比較。

持續集成

持續集成一言以蔽之，就是鍵幫你將測試部署都跑通，有條件的團隊能夠弄一下，極大地提升生產效率。雲龍大神這裏是以Gitlab作例子，我以前也寫過一篇文章，是以Github作例子，但願你們在作開源項目的時候也能極大提升效率（Deploy Using Travis-CI And Github Webhook — webpack doc as an example ）。

前端部署多個環境也是蠻有意思的，這個應該在Node開發的時候比較有幫助，而單純是頁面，用Fiddler, Charles一類的代碼軟件，也能夠達到一樣的效果。

至於ESlint嘛，我建議若是能夠在IDE裏集成最好在裏面先集成了，而後在commit的時候檢測，能夠在集成機裏省掉這一步。

系統測試

分享裏的思路，看起來是基於雲龍大神以前的一個開源項目page-monitor。還沒使用過，但願有人能夠寫寫對比的文章，對比一下這個思路跟基本測試方案的優劣。

敏捷開發

雲龍大神這裏分享的物理看板，是我以爲最有意思的地方。在一直提倡電子化的今天，從新使用物理看板，在外人看來是難以想象的。分享中點出了電子看板的一些問題：

信息輻射成本高
容易造成『信息冰箱』
缺少儀式感
定製性較差

而物理看板有這樣一些優點：

易於建立、易於變動、易於觀察
有極強的信息輻射能力，瞭解彼此工做
有一種特別的儀式感，是一種特別的團隊社交形式
白紙黑字，寫下時間的承諾
方便追蹤進度問題

我以爲其實採用哪一種方式沒什麼問題，但我以爲可以從採納的方式中，不斷優化項目的開發效率，積澱中一套好的牙慧管理方式，纔是最好的方案。不過隨着公司規模的不斷增加，電子化好像是沒法逆轉的趨勢，由於電子化了，之前的數據能夠保存下來，後續可用各類數據、算法進行分析。期待雲龍後面在團隊不斷擴張中關於敏捷開快這一塊的演進。

面向前端開發者的 V8性能優化

謎渡大神此次分享的內容有很多的難度，我特地找他推薦了幾篇V8入門級的文章，讓你們先讀一下。有問題，能夠到TFC大會互動羣裏提問。平時前端開發者主要只是關注寫好本身的JavaScript就好了，但對JavaScript背後的引擎好像比較陌生。但願是次分享能夠給你們帶來有關JavaScript引擎優化的相關知識，使得往後寫JavaScript代碼的時候，可以更容易讓引擎進行優化。

若有謬誤，懇請斧正!