騰訊web前端大會（TFC2017）現場筆記

騰訊前端大會的幻燈片已經發布啦 share.weiyun.com/e6a49556fda…

主唱妹子聲音好聽，漂亮，工程師們特別熱情，一大早前排都被佔領了

到的時候前排都以被佔領，因此圖片不是特別清晰

1、開場致詞

by stonehuang（黃希彤）

以前希彤大神調試代碼乾的最多的事情居然是重啓機器！（IE dom操做的部分接口可能會形成越界而致使藍屏）

每一個技術人都要儘量作到

問題到此爲止

即到我這即知道當前問題能不能解決，若是能解決怎麼去解決

2、the Future of Writing JavaScript

by Nicolas Bevacqua

什麼是TC39

TC39（Technical Committee 39） 是一個推進JavaScript發展的委員會，它的成員由各個主流瀏覽器廠商的代碼組成

如下關鍵詞自行百度

• Array#includes
• Async Functions
• Async Iteration
• Rest/Spread Properties
• Dynamic import()
• Named Captures
• Unicode Escapes
• Lookbehind Assertions
• Class Decorators
• Promise#finally

3、初創公司前端工程體系建設

by 張雲龍

天下武功惟快不破，提升效率

創業中技術選型就像在高速公路上換輪子

前期公司快速發展，在時間就是金錢的創業階段，技術選型更改壓力太大並且有很大風險

土鱉的方法每每最有效

這點我深有感觸，在公司全站vue以後趕上的種種問題（seo等等），可是也不能說是太前衛的方法很差，新技術用的多的感受整個前端團隊都更有激情了

創業不是要減小犯錯的次數，而是要儘可能減小犯錯的成本

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

持續集成：基於GitLab-CI的環境+GitFlow開發規範

系統測試：基於DOM-Diff的自動迴歸檢查系統

經過檢測dom的變化來標誌頁面的變化，測試人員將很方便的只經過肉眼就能方便的進行UI測試

敏捷開發：物理看板

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

by justjavac（迷渡）

int30 int31 or int32

32位系統是int30，64位系統是int31

js中的'加法'

加法操做

V8的算數運算

去優化：

• 生成一個未優化的幀
• 生成從新優化後的機器嗎
• 去優化的消耗很大（從新優化的消耗很大）

v8看到一個變量跟0或運算，v8會把當前變量看成int32處理

SIMD：

充分利用cpu的資源，例如兩個int32相運算，是否是能夠放到int64裏面以達到更快的效率

el.getAtttibute('name')與el.name的相同點不一樣點

由於自己沒有V8的具體研究經驗，因此基本沒有聽懂！！，看到微信羣中一人說了句‘要下課了’，特別貼合如今的狀態

5、遲到的winter老師致詞

終於又到了能聽懂的內容

前端跟客戶端的競爭變爲了前端跟客戶端的整合

大部分時間感受都是在安利weex，因此最後放一張winter老師跟希彤老師的合照吧

6、Start R & B

by 賀師俊（Hax）

什麼是R&B

Reason & BuckleScript

什麼又是Reason：近js語法->OCaml

什麼又又是OCmal：ML語言家族一員（F#等）

什麼又又又是BuckleScript：JS編譯器 做者張宏波

什麼又又又又是...（好吧，習慣性先寫模版）

因此R&B就是 js -> OCmal -> js，一臉懵逼，看圖

R&B牛逼在哪

• 動態類型一時爽，代碼重構火葬場
• 函數式編程
• 類型安全
• Reason是 真函數語言
• BuckleScript 速度編譯速度很是快，生成的代碼可讀性高
• 性能牛逼

7、微信支付大規模前端外包實戰

by rizenguo (郭潤增)

當前微信支付前端外包實戰相關數據

初次嘗試緣由

• 合做溝通成本高
• 文檔不完善
• 外包研發水品相對底

方案

引入外包的挑戰

• 如何解決效率和質量問題
• 如何解決版本更新問題
• 若是解決可持續問題

如何解決效率和質量問題

1. 抽象‘契約式’開發模式、提高溝通合做效率（升級版的後端接口約定）
2. 抽象前端請求生命週期，填空完成業務邏輯開發（生成公共代碼，只須要處理數據請求跟返回值接收）
3. 給低水平的研發賦能，提高前端研發質量（UI組件庫）
4. 提供更簡單的研發視圖，下降研發成本（縮小版的組件拖拉）

以上括號中內容爲本人理解，僅供參考

如何解決版本變動風險問題（改別人代碼的問題）

讓外包團隊推行自動化測試

PFAT：無痛的前端自動化測試

藉助工具保存程序的測試用例視頻，代碼迭代必須知足以前保存的用例，也方便bug的還原（我的理解）

如何解決「可持續」問題

1. 持續培訓
2. 持續平臺建設
3. 持續推動標準化建設
4. 持續增強系統管理分析能力

總結

善於接力和賦能，用有限的人作更多的事，解放勞動力，作更有價值的事情，得到更快速的成長

路遇希彤大大，解答了本身的一些疑惑

Q：關於初創團隊前端技術選型，是成熟仍是先進更合適
A：我以前最先的時候作過一個項目，當時java仍是特別新的後端語言，java程序員大部分都不是特別厲害，並且價格不便宜，最後項目被咱們玩死了，就我我的而言，感受初期，項目能安安穩穩的活下來仍是技術指望更加劇要的

Q：可是若是咱們選的是特別成熟的技術對咱們找人的吸引力不夠大
A：如今沒有必要想這麼多，仍是那句話，什麼體量就要想什麼事情，我上次據說facebook一直在作一項關於chrome的優化，後來發現是google的問題，直接就去找google說大家改改這個地方，google一看是有必要改，而後他們就改了，你看看那個體量又在怎麼解決問題

Q：咱們公司用的是vue，關於單頁面應用seo有什麼好的建議嗎
A：若是大家有論壇博客這些，直接架設一個wordpress作seo而後給主站導流是個相對性價比方案比較高的方案

不是原話記錄，並且是到了酒店又寫的，因此徹底不是希彤大神的語氣，跟希彤大神的合影就不爆了

end

by 邊浩@創客貼