2019年一半已过，这些大前端技术你都GET了吗？- 下篇

在上一篇文章中已经介绍了大前端关于状态管理、UI组件、小程序、跨平台和框架层的内容。在本文中，我会继续介绍编程语言、工程化、监控、测试和服务端，同时也会对下半年大前端能够关注的部分进行展望。

结合我的和团队经历对2019上半年作个技术总结，将各种技术框架/语言/工具分做两个维度：

• 技术采用生命周期
• 技术方向

编程语言

来自 statesofjs的统计，在类JS编程语言上，ES6遥遥领先，TypeScript也得到接近半数的使用量。其次是Flow、Reason、Elm和ClojureScript。

目前主流编程语言已是ES6/7+Babel的组合，用过ES6/7后基本无法再回到原始的ES5时代了，出现了类和模块的概念方便JS代码模块化加载，再加上各类语法糖用的快乐的飞起。async await的语法也替代promise的写法，使得代码逻辑变得更加简洁。ES的规范依旧在快速迭代，每一年都会出一个更新的版本，引入很多语言特性，同时有Babel加持能够将新的语法都转译成ES5版本运行在浏览器中。

TypeScript是做为2019年的编程语言的大黑马受到极大关注，如今有大量框架例如Mobx、Vue3.x都是用TypeScript进行编写，因为TypeScript引入类型可以作到静态检查，所以解决了大量JS运行时类型错误，对于大型项目的代码安全性有很大的帮助。引入TypeScript须要团队对于新的特性有充分的了解，好好利用其中的精华，不然就会变成仅仅把.js后缀改为.ts而已。

在2019 stateofcss也有关于CSS特性使用状况的统计，每一个特性的外圈表明听过过的数量，内圈表示真正使用过的数量。

其实CSS特性的使用覆盖面很大因素取决于浏览器的支持程度，浏览器支持越好越容易得到更高的使用率。能够看到几个高使用率的CSS特性在浏览器支持方面都很是好，除去Opera Mini和少许IE11，其余主流浏览器都能完美支持。

一个有趣的现象是在布局方面Flexbox使用率要高于Grid，可能的缘由在于在低版本浏览器的支持方面Flexbox要更好，但其实在当前主流浏览器的支持度上已经没有区别。另外一个因素多是React Native也是推荐使用Flexbox来作布局，具备较大的群众基础吧。

CSS in JS的理念应该来自React Native，最开始接触的时候至关颠覆，在JS文件中直接写相应的CSS定义，使得组件内聚化达到极致，解决了css全局污染的问题。在web前端，css in js有不少的实现方式，但目前来看仍是比较早期，传统的Less、Sass的这类css预处理框架已经可以比较好的解决一些问题，从编程习惯上也一脉相承，所以css in js理念不错，但要获得推广还须要时间。

CSS Houdini 提出了一个前无古人的的设想：开放 CSS 的 API 给开发者，开发者能够经过这套接口自行扩展 CSS，并提供相应的工具容许开发者介入浏览器渲染引擎的样式和布局流程中。简单的说houdini可让你们去写css 的polyfill从而极大的改善css新特性引入的速度。不过讽刺的是，它自己也须要浏览器支持，w3c标准还处于working draft，大多数浏览器都还没很好支持，你们能够期待一下～

工程化

提到工程化先拿腾讯直播团队分享过的一张图来镇楼，不少小伙伴会狭隘的认为工程化就是webpack或者gulp打包而已，其实这个应该涵盖从项目建立、开发、编译、打包、测试、发布、监控全流程。

项目初始化 项目脚手架目前已经很是广泛，例如create-react-app或者vue-cli都是官方标准的脚手架工具。对于一些稍大的公司都建议本身包装一套本身的脚手架，这样能够沉淀不少最佳实践，例如工程目录结构、lint配置、监控配置、打点配置等等，所以脚手架是落地前端架构标准化不可或缺的一环。

本地开发 lint的规范必定要在项目初期就落地，能够直接拿airbnb的规范或者再定制化一下。lint能够极大的提高代码质量，至少从代码风格来看能够保证统一。 Sonar的引入能够进一步提高代码质量，帮助分析出潜在的问题，同时分析代码的重复率，过长的高数等等，这些都是所谓的代码bad smell，若是任其发展下去，项目维护成本会直线上升。 Mock工具的必要性在先后端联调时就能充分提现，不少时候因为先后端接口定义不清晰致使联调过程就是一个扯皮过程，若是缺少mock工具，前端也会沦为后端接口调试的触发器，前端页面点一下，后端调试大半天，前端小伙伴们伤不起啊。Mock工具至少要有接口定义和本地mock的能力，可以极大提高你们研发体验。

打包 前端工程打包工具强烈推荐webpack 4，强大的插件能力可以让你作几乎任何事情。webpack4中引入了更为强大智能的code split能力，可以极大缩减包大小，通过实践一般减少幅度都在30%-50%，并且在打包速度上也有很大改进，一般也有30%的提高。

监控

当老板给你发一个线上问题的截屏，你本地又没法重现，又没有足够的日志，这时候是否是郁闷，和老板信任的小船说翻就翻了。

监控从能力来看分为几个阶段： 第一阶段：硬件运维能力，例如服务器运行状况，CPU、内存、磁盘、网络等等，在拓机状况下可以快速响应。 第二阶段：应用服务的监控，例如服务可用性、异常流量监控、页面接口的响应时间、App crash等等。 第三阶段：核心业务指标监控，例如业务核心链路数据同比环比的对比等等。 第四阶段：全链路的数据监控，从客户端、前端到服务层，到数据层，可以经过惟一id串联起来，能够方便回溯用户操做，重现问题现场。

很显然要作到监控这四个阶段须要作大量的基础设施，每每大厂都有一套完备的轮子。对于小团队而言，采用开源方案可以快速补全能力。

Cat 是美团开源的业界良心监控方案，对于先后端都有不错的监控能力，数据收集也很完备，可以提供实时的性能指标、健康情况、实时告警等数据，在多家互联网公司也获得实践，实属拯救码农头发的必备工具，你值得拥有～

umeng 做为移动端行为分析工具已经有很是普遍的使用，不过对于大厂而言用户数据很是关键，若是有能力仍是建议自研，毕竟用户的行为数据是核心资产，未来能够基于这些数据作推荐、分析等等有价值的事情。

lighthouse/perf curve/perf budget 这些都是做为性能监控的工具，不只仅能够获得线上环境真实数据，还能在开发阶段提早预警性能问题、落地性能优化的最佳实践，也是小伙伴们不可或缺的好伴侣～

测试

这里一般指的是自动化测试而非手工测试，从测试覆盖范围能够分为单元测试、UI测试、接口测试和功能自动化测试。我所经历的公司或团队，几乎没有能把自动化测试可以作好的，时间和需求频繁变动每每是最大的借口，不过程序员心里都不肯意写测试用例的吧（手动捂脸）。

从落地难易程度来看，接口测试和单元测试最好落地，接口不说了难度不高收益还不错，主要须要对数据准备有些要求。单元测试首推Jest，同时还能统计出覆盖率，可是单元测试要明确好能够测试的范围，通常业务逻辑和底层通用方法比较适合。因此业务逻辑代码从UI层代码抽离很是重要，这时候redux这类状态管理框架就有了自然优点了，里面reducer、action部分就能够单测覆盖。

UI的测试通常对于组件库有点帮助，简单的作法就是经过snapshot进行dom对比，简单粗暴。功能自动化不多可以落地，appium或者selenium都是其中翘楚，须要看业务状况，若是有频繁页面改动，一开始功能自动化写的爽，后续维护成本大的惊人，并且因为功能覆盖时间差，仍是须要大量手动测试的。

服务端

自从出现Node以后，前端技术正式进入服务端开发，从而让前端的小伙伴们能够进行全栈的开发，技术栈的范畴变的更大，对于业务的把控能力也变强了。

Node能够带来几个明显的好处 第一，能够做为BFF(Backend for Frontend)层，解决先后端接口频繁变动的问题，经过BFF层能够实现更加灵活的接口，接口字段的过滤，接口的聚合等等 第二，能够用作SSR(Server Side Render)，经过Node层同构直出，能够将前端渲染代码放在服务端，实现首屏的服务端渲染，提高首屏渲染时间 第三，基于“只要能用JS实现，最终都会用JS实现”定律，Node让前端同窗能够用JS撸后端代码，这个掌控一切的感受太爽了~

Node也存在一些缺点 第一，须要额外的服务器，不少场景下Node层仅仅作接口透传的工做，对于服务器是一种浪费，并且做为一个核心节点若是一旦挂掉整个应用都不可用 第二，须要对Node服务有一整套的打包、部署、监控等能力，这个对于前端同窗来讲提出了较高的运维能力的要求，这些事情每每让前端同窗苦不堪言

服务端最近能够持续关注GraphQL/Serverless，这两项技术对于先后端的架构设计都会带来深远的影响。

2019年下半年展望

中后台的重塑 针对中后台业务特色，缺少详尽的交互设计，缺少足够的前端资源，页面样式相对统一，业界提出经过少许代码或者无代码方式搭建中后台前端系统。目前有的一些最佳实践：Fusion Design，飞冰，Ant Design Pro。你们都是从几个方向去实现中后台前端系统的无代码化，Ant Design Pro基于Ant Design提供了一整套中后台的网站框架和页面模板，对于快速搭建颇有帮助。Fusion Design和飞冰是经过打通设计和编码环节，直接从sketch文档导出相应的页面代码，也是极大的释放了前端同窗码页面的工做量。

Flutter跨平台解决方案 Flutter做为一个跨多端(iOS，Android，PC，Embedded)，具备美观、快速、高效、开放的特色，目前在闲鱼、贝壳、阿里等公司都有落地场景，做为下一代跨平台解决方案咱们能够持续关注，它具备一个很是宏大的野心，背靠Google大厂，可以从系统底层开始抹平各端差别，具备一个强大的技术架构来支持，长期来看仍是挺值得期待的。

阿里前端委员会四大技术方向 如下内容摘抄自圆心的分享文稿

1. 搭建服务：能够看到整个搭建服务不管是在中后台仍是整个无线端，以及 PC 端都有大量场景，这样大量场景须要把整个框架标准化，但愿把里面的元件、组件以及模块标准化，还但愿把这样的服务可以服务于今天全部不管是中后台也好，C 端页面也好，但愿有这样的体系——服务化标准化的方式服务，打通整个体系，这就是为何把搭建服务认为是面向将来最重要的方向。

2. Serverless：可让前端更加贴近业务，可让更多能力下沉。前端转到 Node 体系有一个很大的挑战，可是到了 Serverless 咱们能够不用关注部署，不用关注运维，不须要关注全部的 DevOps，也不须要关注底层数据库的状态，他会让咱们先后端整个的体系像先后端分层同样又往前迈一步。

3. 智能化：由于在 AI 来临的时候，咱们可否从一个 Design 变成一个 Code？今天每一个公司的前端都有大量的设计、大量原代码，咱们经过大量设计稿和原代码进行机器学习，让中间的布局可学习，让中间的元件可学习，我相信将来 D2C 必定可以解决前端生产力瓶颈，让前端从今天大量低端开发、手工工做中解放出来，将精力转移到不少领域深度的参与、深度的突破。

4. IDE：今天阿里的前端咱们作了叫工程中台，工程中台作到了前端代码从提交到发布的管控，固然包括中间提交以后整个代码的编译、构建、检测以及发布。可是在前台的部分，每一个团队都有一个工具，而这个工具在各团队之间割裂的，没法复用。由于工程不只仅是提交到发布，前端工程化应该从编码开始到发布，应该是一个完整的链路、完整的格局

前端技术栈标准化 前端发展到如今，整个技术栈依旧处于百花齐放的阶段，可是对于公司或者团队而言，须要逐步从草莽时代走向正规军时代，这就须要在技术栈标准化上作一些事情。例如对于一个10人左右的前端团队而言，若是仍是三大前端框架并存，那么技术沉淀、代码复用都无从谈起。因此对于一个前端团队而言，标准化的技术栈是很是重要的，须要统一的脚手架、lint配置、mock工具、编程语言、框架、监控等等。

写在最后

大前端的技术很是繁杂，因为我的和团队精力有限，老是有很多遗漏还须要各位小伙伴们补充。对于各个技术所处的采用生命周期也限于我的的体验，老是不免有些争议，我只能尽量作到相对合理。

将各个技术放在不一样的生命周期中，本意不是去贬低某项技术，其实偏偏相反，可以出如今Laggards周期每每说明这个技术获得岁月的洗礼，通过长时间的验证。只是一个时代老是有一个时代主流的技术，这个总结指望你们可以不断自省审视当前的技术栈，保持在业界主流对于将来项目维护、吸引人才都是颇有帮助的。

不管什么样的技术总会有过期的那一天，身为码农仍是要持续不断学习，不要仅仅修炼术的方面停留在各类技术的使用之上，还要多多修炼道的方面，可以拨开技术的表面，看清它背后的原理以及解决问题的本质。

有兴趣同窗能够关注微信公众号奶爸码农，不按期分享关于投资、理财、IT的信息：