引子

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的起源和现状的原因。这确实是一个不错的视角。