FEDAY2018遊記

引子

819跑到廣州參加了第四屆的FEDAY，有不少乾貨也有不少安利，趁熱打鐵整理一下筆記。 如下內容既是記錄，又是我的的一些小想法，有不一樣的見解歡迎隨時討論~

嘉賓簡介

每次FEDAY基本上是網紅們的聚會，本次見到了hax(賀師俊)，CatChen(陳廣琛)，張克軍，Aimingoo（周愛民），還有各業務線的負責人，Uber數據可視化團隊的何珊，京東商城的謝曉立，阿里雲的杜石，還有特邀嘉賓微軟和webpack的開發者Sean Thomas Larkin。下面是個人記錄整理，完整的內容以後大會官網會放出完整的視頻和ppt。

主題

JS面向對象的根基：無類繼承

PPT地址

先拋結論：類繼承的原理就是原型繼承

繼承方式的討論

什麼是類？類的簡單定義就是：有一個過程，在這個過程能產生一個對象的實例，這個過程就是一個類。

但討論繼承，在JS裏最簡單的繼承方式就是原型繼承。在JS1.1中，官方定義了原型繼承的方式。原型繼承是經過對象上的原型屬性指向別的實例，達到鏈式訪問的繼承方式。以下的方式：

// 父類
function Base(name) {
	this.name = name;
}
Base.prototype.getName = function(){
	console.log(this.name);
}
// 子類
function PriBase(name, type) {
	Base.call(this,name,type)
	this.type = type;
}
PriBase.prototype = new Base()
複製代碼

到了ES5以後，引入了多個對object的屬性定義的方法，經過這些對屬性的增刪改查的方法，能夠說明幾個觀點：

1. 對象就是屬性包。
2. 原型繼承的本質就是屬性包的鏈式訪問。
3. 對象方法是一種函數類型的屬性。

在ES6中，定義了類的繼承方式。

class PriBase extends Base {
	constructor() {
	 ..
	 // super();
	}
	static foo() {
 	 ..
	}
	more(){
 	 ..
	}
}
複製代碼

其中嘉賓說到一個點，在ES6進行對象函數屬性的定義時，他會標記名爲HomeObject的內部屬性指向代表方法的歸屬對象。這個HomeObject的指向是可變的，在類的繼承中，會調用super方法，而super方法是根據HomeObject決定指向的對象。

homeObj = Method[[HomeObject]];
super = Object.getPrototypeOf(homeObj)
複製代碼

因此類繼承的核心原理，就是依賴於無類繼承這一特性而實現的。

而後接下來引出了原子對象的概念，下面是一個理論，衍生出了元系統的概念。

Javascript的元系統

ECMAScript中只有兩處說起到「Meta」這個概念，一處是說明ECMAScript的規範類型（a specification type）是用於描述和實現語言類型（language types）的元值（meta-values），另外一處則是惟一被稱爲「元屬性（Meta Property）」的new.target。

在介紹這個理論以前須要定義一下原子，來構建完整的元系統。

原子Atom

定義：原子是JavaScript中的對象的最小單元，它是對象但不繼承自Object()；以原子爲原型的對象也會被稱爲原子對象。

如上所述，JS中的對象就是一個屬性包，那麼若是爲空集時，便是最小的形態。一個沒有圓形，切自有屬性集爲空的對象，就是一個原子。

原子是能夠被建立出來的，以下面所示：

var atom = Object.create(null);
var atom = Object.setPrototypeOf(new Object, null);
複製代碼

能夠有一個方法來判斷一個元素是否爲原子，根據原子的定義不繼承自Object：

function isAtom(x) {
    switch (typeof x) {
        case 'object':
        case 'function': return !(x instanceof Object);
    }
    return false;
}
複製代碼

原子系統的引伸

當有了原子，能夠繼續衍生各類其餘的概念，如元、元類型等等：

元：能產生原子（atom）的一個過程稱爲元（meta）. 元類型：全部元（meta）的類型稱爲元類型（Meta types）. 元類類型：元類是一個產生類（class）的過程.

今後能夠不斷引伸，建立出一套元類型系統。

感興趣的同窗能夠繼續關注周老師關於元系統的blog文章：

• JavaScript的元系統
• JavaScript中建立原子的幾種方法
• 元類型系統是對JavaScript內建概念的補充

還有開源項目metameta

我的感悟

本主題是從JS中的繼承的原理出發，逐步引伸出了元類型這個概念，再逐步的擴充到整個元系統。這個思路很值得借鑑。

實話實說這部分尚未太搞懂，很期待周老師後續的blog。

kepler.gl在海量地理定位數據可視化的應用

PPT地址

做者何珊是Uber數據可視化團隊的創始人。題目顧名思義，kepler.gl是做者及團隊開源的一套數據可視化的地圖圖表，對大量地圖定位數據提供了多種圖表進行展示。

嘉賓由自身經歷出發對數據可視化的觀點進行了闡述：她認爲數據可視化分爲了四個部分：設計，統計，代碼和講故事。用數據結合一些設計手法講故事，獲得可行性的方案。

數據是冰冷的理性的，圖表是生動的感性的，將理性的數據感性化，增長動態的表現同時才能增長視覺的感覺力。從需求出發，尋找數據之間的差別化，將數據分層，來轉化爲不一樣的類型，如點圖，熱力圖，密度圖等等。

同時，運用技術的手段進行框架性能的優化。由於要承載大量地圖數據，所以要從效率的角度優化框架。在CPU計算的同時，採起GPU計算輔助加強性能，例如如下幾個方面

• 數據到像素之間的轉換，例如數據向屏幕上的點像素的計算轉換，利用GPU多計算單元的特色進行分佈計算提升效率
• 數據過濾，在一些操做致使數據發生變化時，利用GPU對數據進行一部分diff操做，相似diff算法進行剪枝，優化在線計算性能

同時把graph(圖形渲染)和reducer（數據處理）分開，對框架的擴展性有了更好的支持。

另外提出了利用GLSL Shaders對GPU進行編程的思路。

我的感想

不一樣的圖表的使用場景不一樣。一樣的數據選擇對的圖表能夠透露更多的信息。另外可視化和數據並不衝突，在目前互聯網公司的節奏，數據和可視化視圖應該同時結合，以直觀並讓人信服的方式展示數據。例如一樣是二維，若是能增長表示濃度或者時間的第三維，能夠得到不少的額外信息。

結合業務來講，這適用於積累大量數據的應用場景，好比說打車的應用場景，能夠利用當前積累的數據，作更多有效分析和轉化進行處理。

嘉賓的我的經歷頗有意思。建築設計出身，作了設計師以後發現技術老是實現不了本身設計的成果，所以又學習CS，將專業交叉拓展，並應用於數據可視化這方面，以後提煉工具開源框架，整個過程當中都很明確本身的目標，並能爲目標不斷的努力。

複雜業務前端團隊的進化之路

PPT地址

京東的凹凸實驗室，仍是挺有名的。再加上前一段時間推得react轉微信小程序的taro，所以對這部分期待很高。可是整體感受來講只是講了個大概和思路，並無深刻的分析這麼架構的根本緣由，我的以爲心路歷程不夠飽滿。感受更像是集團框架的一個大致介紹，下面簡單記錄下：

背景

首先介紹了下京東商城複雜業務邏輯的背景，如PC、手Q、小程序等等業務涉及多端多平臺，須要在工具迭代和流程優化兩個方面去作建設。

工具迭代

工具迭代爲了解決兩個問題：1. 優化開發體驗。2. 進行性能優化。 所以作了前端工程化和靜態資源管理兩個方面的工做。

爲了提高開發體驗，作了如下幾點：

1. 對項目制定統一的規範。相同的目錄結構規範項目。
2. 在項目中引入組件化的概念。利用組件來拼裝頁面。
3. 自動化編譯。定義一系列的編譯任務進行自動編譯，相似於腳手架的流程。

在性能優化方面，作了一下幾點：

1. 提升首屏性能。考慮在編譯環節直接打包首屏，減小HTTP請求提高首屏加載速度。
2. 按需加載。樓層選擇一步的方式按需加載，而且作離線緩存，記錄樓層的版本號。
3. 基於資源表加載。區分同步和異步的資源分別加載，只對模板中改動的組件操做。
4. 靜態資源預加載。

而後還有造輪子的過程，例如爲了考慮兼容IE8，作了類React的前端框架Nerv。一樣爲了適應小程序的節奏，爲了適應React的開發模式，作了Taro框架。結合前端流程工具Athena最終造成如下的技術選型：

流程迭代

在流程迭代方面，首先是梳理原始的研發流程，作了如下方面的建設：

1. 創建接口文檔&Mock平臺。爲先後端聯調作建設。
2. 作好監控報警服務。如數據監控、素材監控、24h監控告警、DOM監控等等。
3. 增長自動UI測試。保障頁面100%可用。

系統多了，業務複雜就容易出現浪費資源的狀況，須要將各個項目高效整合，他們主要是系統化和自動化的思路來對鏈路進行整合。

總結，統一的開發工具加通用的開發流程，覆蓋了從項目建立到上線監控的完總體系。大體介紹了京東的前端框架的進化，複雜業務的統一研發。

我的感想

嘉賓講的比較寬泛，並且我的感受從角度方面略有些問題。前半部分感受是爲了完成上級KPI完成的框架的構想，例如知足各方面的兼容以及強行造輪子。能夠從目前現有結構出發，結合業務實際來聊一下如此架構的緣由及思路。以及大體介紹下不一樣解決方案的原理和解決的場景。

比較能夠借鑑的是他們對前端開發流程的抽象思路。例如業務場景很是複雜時，如何進行流程上的抽象，在每個具體的步驟如何利用現成的框架，現成不知足的時候，又如何進行造輪子的分析，是不斷擴展前端工程化方面的工做。

每一個團隊應該都是相似的解決思路，圍繞本身的業務場景提煉出一套開發流程，像京東這種大前端的框架思路，還須要集中資源去強化落地。

要是想詳細瞭解京東前端解決方案，能夠看這篇文章咱們是如何作好前端工程化和靜態資源管理。

如何正確點開技能樹

PPT地址

這個主題更多的像是職業規劃方面的分享。你們的職業規劃講座聽得也比較多了，我就只羅列其中的重點吧。

首先要肯定你的興趣更多的在哪一塊。嘉賓大體分紅了三個部分：

1. 產品向：2C，面向消費級用戶。
2. 基礎架構：2B，着重於解決其餘人使用中的服務問題。
3. 產品基礎架構：2B&C，能夠考慮往框架的方向發展，作一個可伸縮的服務/全面的框架。

至於前端、後端、和全棧的考慮，有一個參考標準，就是選擇你願意主動付出努力的一條路。職業道路的規劃，對職業生涯的前期有幫助，越到後期越須要全面的瞭解。

選擇對頭幾年有興趣的點出發去考慮這個問題。

職業生涯的劃分方式

嘉賓一言不合就開車。以開車爲例將職業發展劃分爲了幾個階段：

1. 學徒期student：明確本身的興趣，喜不喜歡駕駛體驗
   • 搞清楚是否喜歡編程
   • 去作大量的練習去不斷試錯
2. 實習期new driver：開始上手，虛心向老司機學習
   • 嘗試解決問題並進入學習階段
   • 注重代碼質量，學會提問問題
3. 老司機experienced driver：可以自信駕駛
   • 熟練能夠獨自處理一些問題
   • 會焦慮不耐煩
   • 開始創造，並能有效根據項目安排去完成項目
4. 專業的courier：以此爲生，能明確的瞭解如何從A點到達B點
   • 準時可靠，目的變成了手段，從商業目的的角度去解決問題
   • 有必定的項目規劃能力，有必定的風向敏感性。
   • 能夠及時調整目標，須要管理其餘人的指望
5. 搞事情的人trip organizer：能解決一些額外的基礎框架問題
   • 能彙集一羣人完成商業結果，領導力，協同能力以及規劃能力
   • 能夠抽離指標和方法，帶領團隊，而且有較高的招人和指導能力
6. 探險家expedition：不知足於現狀，有着更多的發現
   • 尋找新的商業機會，並集合你們去實踐
   • 沒有確切的目標點，能夠不斷的擴展探索邊界

這是一個頗有意思的模型，看得出嘉賓但願你們不要侷限於自身的技術領域，而能有更多的拓展。

我的感悟

其實職業規劃的能力，就是一個工程師成長的路程。須要不斷從專業能力出發成長，再逐步去進化產出產品和運營的sence，來去管理孵化更大的團隊。

一樣是較expedition級別來講，須要對領導力有着更多的要求。同時，在大公司和小公司要求也不一樣。大公司不用太爲團隊所困擾，專一目標方向，戰略層面須要由縱深的眼光。小公司則要求更加全面化，從招人、找錢，到產品的不斷打磨，都是一個逐步進化的過程。

Time in JavaScript

顧名思義，Hax本次的主要內容是講Javascript中跟時間有關的API。主要的內容，大體介紹了JS中Date對象的起源，以及如今常用的時間庫，以及將來最新的temporal提案。

ppt很是簡約化，下面是大體的內容介紹：

起源

JS當時內建的Date對象是直接照搬了JAVA1.0中的java.util.Date的設計。可是這是一個有錯誤的API，在JAVA1.1中被廢棄。可是JS的Date卻一直保留下來並沿用至今。

根據各地遵循的立法不一樣，日期表達方式不一樣，會在時區方面，存在着不一樣時區秒和微妙之間的差異。

問題

現有的Date仍有一些問題存在：

1. 有不少toXXXString()的api，可是不支持自定義格式
2. 只有UTC和當地時間，不支持時區的設置
3. 缺少一些經常使用的計算api，例如時間的加減等等
4. 存在不少棄用的api
5. 精度只支持到毫秒級

相似的問題還有一些使用上的，不符合常規認知的，好比說下面的代碼

new Date(2018, 4, 16)
// 2018-05-15T16:00:00.000Z
複製代碼

月份傳入4，生成的是五月，是由於月份從0計算的等等問題。

推薦時間庫

1. Moment.js：經常使用的時間庫，對不少經常使用的格式有很好的處理
2. date-fns：對現有的date作了很好的支持，提供了不少轉換方法
3. js-joda：一個js的不可變日期和時間庫基於ISO8601。

提案

這是提到的時間提案，引入了CivilDate的概念，不進行任什麼時候間和時區的轉換。

• 返回對象格式，對經常使用hour，minute等屬性進行了封裝。
• 支持傳入對象進行日期的操做，媽媽不再用擔憂我算錯日期！

還有其餘的新特性有待發掘。

我的感悟

該分享是專一於某一個特性深挖，818歷史起源和目前的發展，以及關注下一代的發展趨勢。

平常常常會使用Date，也確實吃過客服端服務端日期不一致的坑，但卻沒想過深挖一下Date的起源和現狀的緣由。這確實是一個不錯的視角。