騰訊web前端大會(TFC2017)現場筆記

江江也叫Glowin發表於2019-02-26

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

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

到的時候前排都以被佔領,所以圖片不是特別清晰

一、開場致詞

by stonehuang(黃希彤)

之前希彤大神除錯程式碼乾的最多的事情竟然是重啟機器!(IE dom操作的部分介面可能會造成越界而導致藍屏)

每個技術人都要儘可能做到

問題到此為止

即到我這即知道當前問題能不能解決,如果能解決怎麼去解決

二、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

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

by 張雲龍

天下武功唯快不破,提高效率

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

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

土鱉的方法往往最有效

這點我深有感觸,在公司全站vue之後遇上的種種問題(seo等等),但是也不能說是太前衛的方法不好,新技術用的多的感覺整個前端團隊都更有激情了

創業不是要減少犯錯的次數,而是要儘量減少犯錯的成本

前端架構:元件化+子系統拆分

持續整合:基於GitLab-CI的環境+GitFlow開發規範

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

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

敏捷開發:物理看板

四、面向前端開發者的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的具體研究經驗,所以基本沒有聽懂!!,看到微信群中一人說了句‘要下課了’,特別貼合現在的狀態

五、遲到的winter老師致詞

終於又到了能聽懂的內容

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

大部分時間感覺都是在安利weex,所以最後放一張winter老師跟希彤老師的合照吧

六、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 速度編譯速度非常快,生成的程式碼可讀性高
  • 效能牛逼

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

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 邊浩@創客貼

相關文章