博客的更新频率与我的工作时间呈现严格的负相关，14 年 13 篇、15 年 10 篇、16 年 4 篇、17 年 3 篇。最近一次更新博客，已经是将近 8 个月之前的事情了。上学的时候还经常感叹，为什么关注的很多大牛的博客都渐渐不更新了呢？工作几年后终于有了答案：忙 和 懒。
当然如果你观察的周期足够长，你会发现有些大牛的博客在沉寂若干年后又开始焕发第二春。那是因为他们已经成功跻身中层管理，阶段性的目标被调整为团队管理和影响力提升，自然又更新的勤快了起来。
言归正传，2017 年发生了很多有意思的事情。无论是技术上，工作上还是生活上，都值得被记录下来，与大家分享。算是对过去一年的一个交代，也算是对新的一年的一个期许。
TypeScript 与 VSCode
2017 年最兴奋的事情就是上手了 TypeScript。
大概从 17 年 6 月份开始，因为一个新项目的契机我开始全面详细的学习 TypeScript。虽然自诩不是一个抵触新鲜事物的人，但是第一次让我去学习 TypeScript，其实我是比较抗拒的。
第一，我始终觉得「静态类型 + OOP」 的设计完美的体现了冗余的仪式感之「美」。明明一行代码就能解决的问题，非要先定义一个接口，再实现一下，最后再实例化一下才能使用。
其次，微软在开源届的名声一直不算太好，各种 .NET 的生态衰亡、SilverLight 等技术的昙花一现以及 IE 本身对前端工程师的一万点伤害，让我十分怀疑 TypeScript 是否是一个值得学习的技术。
最后，在学习 TypeScript 之前我已经非常熟练的使用 ES 6 甚至是 ES 7 中的诸多特性，感觉 TypeScript 除了静态类型检查并没有带来太多的红利，学习的投入产出比不高。
但是最终让我心甘情愿爱上 TypeScript 的原因也很简单：TypeScript + VSCode 的开发模式非常适合团队协作模型下的大型项目开发。
正是因为新项目是一个非常大型的 React + Redux 单页应用，有大量的组件和模块需要被各个场景复用，TypeScript 强大的类型检查功能帮助我们基本上很少浪费时间在公共组件或者模块的调用方式讨论上，要用什么公共组件，直接鼠标悬浮在对应的地方就能有完整的提示，参数传的不对、传少了、返回值用法不对等等问题都能很直接的在编辑器中体现出来（VSCode 功不可没）。这些特性在团队协作的大型项目开发工作中显得尤为重要。
当然，也不是说 TypeScript 不能用在小型单人项目中。我也正在计划把自己 2、3 年前个人开发的很多技术项目逐渐往 TypeScript 上迁移。因为强大的静态检查类型可以帮助我们检查很多低级的运行时错误，比如变量名拼错。
还要多提一句的就是 VSCode。
在 VSCode 之前我一直是 Sublime 的死忠，期间 3 次尝试切换到 VSCode 都以失败告终。但使用 TypeScript 开发后，配合 VSCode 做各种代码间（甚至是 node_modules中的文件）跳转、类型定义查看、错误提示等功能，简直流畅至极。
同时由于 VSCode 对开发者暴露的是 TypeScript 的 API，使得你想编写一个插件简直易如反掌（对比下当年想写一个 Sublime 插件苦兮兮的学了很久 Python）。
大数据体系
都说大数据像 teenage sex，但是作为在阿里数据中台的直接参与一线数据产品开发的前端工程师，2017 年我自认为还是摸到了一些大数据入门级知识，如果类比 teenage sex 的话不知是否达到二垒。
我是怎么和大数据结缘的呢？故事还要从阿里内部的 Clue 前端监控平台说起（互联网无法直接访问😢）。大约在 2015 年上半年的时候，我注意到我们的很多前端故障都是可以在用户向客服发起投诉之前被捕捉到的（比如点击某个按钮时有 JS 报错导致弹框没有打开等），但是我们对自己写的代码在用户浏览器中运行的情况如何是完全没有方法感知的。
于是我开始规划做一个异常监控平台，名字就叫前端稳定性平台（Frontend Stability Platform，FSP），一个非常符合程序员风格的名字。
要做一个监控平台，首先要解决数据从哪里来的问题。对于前端监控来说，很显然需要在客户端部署采集代码，监听全局 JS 异常，然后上报的日志服务器。在日志服务器上，数据以文件的形式按照约定的分隔符储存。然后需要类似于 logstash（阿里内部叫 TT）的工具定期去日志服务器上拉取日志文件，再传递给实时或离线数据处理服务。经过一系列的过滤、汇总后，最终生成的数据根据查询的需要储存在不同类型的数据库中，供给监控平台的 Web 服务进行查询。
这个监控平台的工作原理我在团队的知乎专栏中有一篇文章进行了更详细的描述，这里就不再赘述。
当然真正的大数据可没有上文三言两语讲的那么简单，除了技术上如何处理，目前企业大数据面临更大的问题是如何规范大数据建设、数据如何发挥价值（从业务数据化到数据业务化）等等。但很高兴我起码算入了门，能把流程走通，还能最终产品化落地（最终命名为 「Clue 前端监控平台」，寓意为业务发现异常的线索）。
说到大数据不得不提的就是机器学习和人工智能。我也很自不量力的参加了 Andrew Ng 在 Coursera 上非常出名的机器学习课程，并成功卡在了理解逻辑回归损失函数（Loss Function）的那一大堆公式里（FYI，逻辑回归仅仅是第二章的内容）。
其它技术
2017 年在技术上还有很多琐碎的事情，比如年中闹的满城风雨的 React License 事件，虽然最终以 React 使用 MIT 协议暂告一段落，但是也间接捧红了 preact 等不少类 React 但协议无害的替代产品。据我所知百度已经全线禁用 React，即使协议已经不再是头等主要的问题。
此外 2017 年我还研究了一段时间的 ServiceWorker，以及现在越来越热的 PWA 概念。感觉这是比 ReactNative、Cordova、Weex 等方案更激进但也能更进一步降低前端工程师写移动 App 门槛的方案。如果标准制定的够完善，各大浏览器厂商跟进足够给力，相信会引起新一轮技术革命的高潮。
另外值得一提的是 Chrome Headless 的发布，终于把很多自动化场景从 PhantomJS 或 Selenium 的噩梦中解救了出来。在 Chrome Headless 发布不久，我们团队就开发了一款基于该技术（及 pupeteer）的自动化截图技术产品，无论从性能还是使用体验上来说，都称得上是质的飞跃。
拥抱变化与可持续发展
很多人说到阿里巴巴脑海里第一个反映出来的词就是「拥抱变化」。没错，今年我也被「拥抱变化」了。
坦白说当变化真正发生的时候，我不可避免的还是有一些心理上的起伏。这让我想到了生活大爆炸里面 Sheldon 对内稳态（hemeostasis）的痴迷，谁不希望做自己擅长的、早已驾轻就熟的工作呢？谁不希望面对的同事是合作多年、默契深厚的好伙伴呢？谁不希望负责的项目运行稳定，不会有任何大麻烦呢？
内稳态固然让人痴迷，但是阿里内部有句土话我也很认同：当你觉得困难的时候，就是你在成长的时候。如何定义公司里的老油条？就是那种工作三年全靠入职前三个月经验的人。
我不希望成为这样的人。
在变化之外，2017 年我悟到最重要的一个道理就是要坚持可持续发展。
以前总觉得自己是个热血青年，熬夜写代码完全不在话下，有时候睡着睡着脑海里突然冒出来一个想法，一个鲤鱼打挺就坐起来开始编码，第二天一杯浓咖啡就能再战一整天。
而现在，偶尔业务上线或赶关键时间点熬到 2、3 点，第二天整个人都会精神不振，多少杯咖啡都没有救。
身体是革命的本钱，毛主席诚不我欺也！
写在最后
今年侥幸晋升到了 P7，背上了「专家」的 title，心里依然很惶恐。
对技术，深度和广度都需要继续拓展；
对个人，调整心态，健康工作，坚持可持续发展成了第一目标；
对 2018，不立任何 flag，佛系生活，免的年终打脸。