前言
今年一直犹犹豫豫到现在还没写年度总结，往年的总结往往是把各种社区的经历放一起就可以把整篇年度总结堆积得满满当当的。但是今年笔者仔细想了好久也没想到特别多的经历。今年社区混得更少了，没有那么多在社区的产出。往年我会有很多在社区的足迹，譬如说参加各种技术大会比如 SeeConf、D2 等等，譬如说会去如 Etalk 做讲师做一些外部的技术分享，还有撰写《剖析 Vue.js 内部运行机制》以及在社区发表各种技术文章。但是这方面今年做的并不那么好，看了 github 的打卡记录有点稀疏。
虽然今年没有那么多社区的输出，但是笔者一直在阿里内部的 ata 平台上输出一些更贴合业务的技术文章，在自己的私人的 lark 上时不时记录一些对技术对业务的思考（加密的），笔者认为今年比起往年有了更多的对业务以及对技术的思考，成长也是远超前几年的，收获还是非常大的。怎么看成长大不大，很简单，其实就是再往前回顾一年，觉得前一年的自己就是个sha逼，那么这一年估计成长不少（笑
往年的年度总结我会清一色的流水账+吹牛逼，今年想换个风格，想更大篇幅地写一些笔者在工作上的经历、思考以及收获，所以笔者给它加了一个副标题——我在阿里云做前端。
文中有一些引用是我发在阿里内部平台上的一些文中，如果外部的同学想看的话，文末有招聘，欢迎发我简历（笑
2019 年度关键词：云通信、拥抱变化、阿里云业务中台体验技术、全栈、数据全链路、微前端
云通信
最早在今年年初的时候，笔者还在负责云通信的业务，因为上半年有一半多的时间投在了这块业务里，也还是拿出来先讲一下。
在维护老项目正常迭代的同时，我们还需要抽出时间去做创新型业务的新产品的从 0 到 1 的开发。当时团队内只有三个人维护云通信的项目，特别是过年那段时间，忙得跟狗一样。新的业务越来越多，对接的 PD 以及业务方也越来越多，怎么办？而面对越来越多的业务线以及快速上线的需求，如何保证线上的稳定运行以及如何第一时间发现线上的问题，也成了我们必须处理的问题。
1）提效
当然，加人是最快最有效解决资源瓶颈的方法，但是“加人”为“提效加点速”的简单粗暴的手段显然不可取。首先是优秀的前端到底有多难招，大家应该都是有目共睹的，很难快速招到合适的人。其次，工程师的价值在于将复杂的业场景抽象为可复用的能力，用技术的手段沉淀出快速可复用的研发体系，将更多的能力赋能给业务。为了做 100 个页面，我们更应该将这 100 个页面的共性抽象出来快速复用，而不是要去招 100 个前端来开发。不然如果是 1000 个页面， 10000 个页面呢？
当然，招不到人是主要原因，能招到 100 个前端的话欢迎提供给我简历，文末有招聘（笑
那么，提效也自然成了我们在没法快速增加资源的情况下解燃眉之急的最好方式了。虽然在 0202 年再细说组件库已经没有特别大的意义了，但是把业务抽象成一个个常用的业务组件，对于云通信这样的产品功能重合度高的业务场景，还是能解决很多重复劳动的问题的。与设计规范打通，与设计师的视觉稿达成一致的规范（当然双方都要有所妥协），能省去不好扯皮子的时间。当然能够合理“砍需求”，也是一个非常有效的提效方式，当然不是把一些核心项目给“砍没了”。而是在我们理解了业务以及需求价值的前提下，把一些没有价值，或者投入产出比并不高的需求砍掉，把有限的时间跟经历投入到更有价值更有意义的事情上去。关于“砍需求”，推荐看看《会向业务“砍需求”的技术同学，该具备哪6点能力？》。所以，笔者在需求评审会上对 PD 说的最多的话就是“不要‘你觉得’，用数据说话”。
那么，数据也就成了我们研发体系中非常关键的一环。
2）数据
由于复杂多变的业务场景，我们不止要为研发同学提供数据去“砍需求”，我们也要服务于业务，推动业务做出更科学的决策。我们基于集团的黄金令箭，封装了一套自带业务属性的埋点 SDK，笔者把 SDK 做成了一套能够快速接入项目的业务工具，详细内容可以看笔者的另一片文章——《魔库埋点二三事——组件篇》。以及一个通过解析项目代码编译时期的 AST 自动提取所有点位信息以及业务属性，可以快速抽离各个项目的埋点配置的工程化工具，这部分详细内容可以参考笔者的另一偏文章——《魔库埋点二三事——工具篇》。最终，我们的数据会沉淀在我们的数据平台——魔库上，除了提供各种 pv、uv、点击率、跳失率、行为链路、转化漏洞等等基础数据外，我们开发了一套体验大盘，用来综合衡量各个产品的用户体验，及时发现各种链路中的体验问题。
也因此，我与魔库结下了不解之缘，后面还有数据方向的其他的内容，后面会提到。
3）稳定性保障
我们也做了很多稳定性保障的工作，为了第一时间发现以及处理线上的问题，做到 1-5-10 原则——1分钟发现问题，5分钟定位，10分钟解决。因为前端是离用户最近的，所以理论上应该是可以最快发现产品在用户操作测以及体验的一些问题的。
- 基于 arms 监测 api 成功率、js 错误率等指标
- 完善的上线流程以及 code review
- 基于魔库监测数据的异常波动
- 常见的坑持续输出汇总，避免大家重复踩坑
- and more
变化
在阿里，唯一的不变是变化。
今年算是感受颇深。
但是这些变化给笔者带来了很多正向的成长、更广的视野以及更大的接触面，比起拥抱变化中去适应新环境的一小段时间的“过渡期”，犹如涅槃重生，每一次变化都带来了新的成长与收获，这才是最好的。
笔者在今年上半年因为业务变动进入了阿里云业务中台体验技术团队，更大的业务场景，更多的挑战以及更多能做的事情让笔者非常兴奋。
数据全链路
前面说到，笔者与魔库结下了不解之缘之后，来到阿里云业务中台体验技术团队以后，笔者就开始负责数据全链路的开发工作。从最早跟着老大哥弱冠，跟萌妹子雏恬一起没羞没臊地开发，到现在由笔者来 owner 整块数据能力，还是有了非常多的成长与收获。更详细的内容，笔者会在今年年前输出一篇《我在阿里云做数据——魔库》的文章来详细讲讲我们这一年基于横向覆盖多业务场景下，如何用数据赋能业务，用数据能力助力自运营体系。
1）平台：出现问题，解决问题
无论是对产品持续迭代优化，还是精细化运营，数据的价值非常大。但是当不同的角色（运营、UXD、PD等）希望通过各种现有数据平台去看数时，却出现了一些问题：
- 平台分散，口径不一致 当我们有看数需求时，由于看数平台的分散，我们需要从多个平台上获取不同的数据，从这些数据的关联中分析出相应的价值，但是这些平台由于口径不一致，各个数据之间并存在一些差异导致分析时候由于数据的误差带来结果的不一致。
- 无接入能力 使用二方数据平台时，我们的一些业务定制化能力无法很好地接入，一些业务比较关心的业务数据无法在我们的数据中做定制化及差异性的扩展。
- 数据查询慢 由于平台的分散，我们需要去多个平台获取各个我们需要的数据，效率低下。
魔库就诞生了，最早魔库诞生是为了解决上述问题，给予这些业务丰富的数据支撑，通过业务产生的数据，沉淀成数据能力反哺业务，为业务的价值提供可靠的数据支撑。后来由于业务的变动与交接，魔库肩负着更大的责任来到了阿里云，支撑起阿里云从大官网营销体系全链路的监控（赋能中长尾精细化运营），到售卖链路的数据支持（支持了几乎所有云产品售卖业务数据），并提供了对于所有中后台以及搭建业务的数据支撑。 魔库是一款底层数据基于黄金令箭的封装，基于阿里云业务的定制化业务数据中台。目标是打造数据化、智能化运营的支撑中台，面向未来可持续发展的用户平台。
2）前端->全栈+BI
我们知道，前端这几年发展地如火如荼，已经把触手伸到了各个领域，前端的范围也越来越大，能做的事情也越来越多。而在数据全链路的项目中，我们终于也把我们的触手，伸向了 BI 这个新领域。
笔者开始尝试对原始数据进行数据清洗，数据回流，最终把百万千万级的海量原始数据转化成可以通过 Node.js 直接访问的少量的有效数据。完成了多个纬度数据能力的输出，通过这些项目熟悉了整套数据开发的流程，也为笔者后面做为数据中台的开发 PM 打下了坚实的基础。
前端是个横向的团队，支撑了横向的多个业务，这也有利于我们可以通过横向的视角去看到更多的问题以及机会。但是比如数据平台这样支撑横向的业务的平台，很难找到一个单独的业务领域开发的后端同学来帮助支持这块业务，所以我们也只能撸起袖子自己干。
刚毕业那会儿做了两年多的 C++ 开发，对于后端开发一直算有些许经验，借着开发魔库的机会，开始负责魔库后端的开发（基于 Node.js）。除了做可视化展示，把数据用更直观的方式输出给业务，有了后端的能力，可以做的事情就多了。我们通过 OPEN API 把数据能力直接输出给二方平台，通过配置查询业务报表来给业务方快速提供更多带业务属性的数据能力，通过数据的告警将各种业务或者数据问题反馈给相关同学，通过各种数据自动化衡量每一个项目所带来的价值等等。
3）提效工具
由于我们需要知道每个项目有哪些埋点信息，形成一套项目与页面、点位信息的映射关系。根据这些信息我们更方便地从 odps 的海量数据中拉出我们需要的那部分数据，所以需要通过平台管理后台录入的方式把项目的埋点信息写入到平台中去。然而这样的方式低效又繁琐，对于多人协作的大项目没有很好的机制去难保障每个人都能把所有信息录入，一些不理解我们的埋点体系的外包同学开发更是无法保障所有信息齐全。
于是我们通过解析项目代码编译时期的 AST 自动提取所有点位信息以及业务属性，可以快速抽离各个项目的埋点配置的工程化工具。通过工程化插件的集成，我们可以保障每个项目在上线前会自动提取所有项目中的埋点信息，并通过 OPEN API 录入到我们的平台。
4）平台打通
由于我们的大量营销场景以及中后台场景通过可视化搭建来完成常用页面的开发工作，搭建页面的角色有很多，有可能是PD、运营、外包同学甚至会是测试同学。我们无法保障每个做搭建的同学理解我们的埋点体系，但是他们对自己搭建的页面（平台）确实有着强烈的看数需求。
于是我们就需要通过自动化的手段去完成一整套埋点编码、点位上报、信息录入以及数据提取的流程。魔库通过 OPEN API 将这部分能力透出，通过将搭建平台与魔库的打通，完善了一整套的自动化数据流程。更细节的内容可以看笔者的另一篇文章——《我在阿里云做中后台-xcloud 数据体系》
微前端
年底的时候由于新的业务场景，也研究了一段时间的微前端，看了各种 JS 与 CSS 的隔离方案。最近还在做这方面的研究与尝试，对这方面有研究的小伙伴也欢迎来一起聊聊，说不定会擦出新的火花。这块先不细说了，等做完了再说。
其他
今年社区出没得比较少，就参加了一下 D2 ，明年希望还是多出来走走看看，学习学习大家在做什么。以及一篇水文——《染陌足迹——14届D2前端技术论坛》。
三年没打球了，今年打了两场比赛几乎累瘫，脑子虽然还在线上，但是脚总感觉慢半拍。明年希望多运动运动，把暴涨 30 斤的体重控制住。
思考与收获
最后写一些笔者这一年对于自己的岗位、技术以及业务方面比之前更深刻一些的的理解、思考与收获。
- 对岗位以及业务的理解 由于协作以及分工等原因，前端对于业务的理解深度通常被认为比后端要弱一些。但是纵向比不过，横向的覆盖面前端团队是更广的，前端团队的业务覆盖横向的一整个面，我们可以对整个 BU 的业务进行一个横向的整合，从全景的视角去看待我们的业务。基于业务之间串联进行多角色多业务的赋能，横向多个业务之间复用的功能可以进行抽离，形成通用的能力平台。通过全栈开发，Node.js 赋予我们更敏捷的平台开发能力，横向业务的串联以及横向业务之间的一些共性的抽离，沉淀成能力去做一个横向的赋能，是我们更可以多发力的地方。
- 技术是工具，也是赋能商业的手段，而不是目的 很多刚毕业的技术同学会陷入一种误区，认为把某个框架或者某些技术的实现细节或者实现原理吃透就能成长为技术大牛，或者是为了用某个技术或者某个框架而去做技术选型或者凭空实现一些很虚幻实际上并不能产生价值的功能。热爱研究技术当然是每一个技术人员需要具备的品质，阅读源码也是技术人员必须具备的一种能力。但是笔者更倾向于带着问题去研究技术，用技术手段去解决业务的痛点，技术是解决问题的工具，而不是结果或者目的。
- 不断挑战自己，拓展边界 很多时候人容易陷入舒适区，更愿意守着自己的领域做着自己特别擅长的事情。可能就是每天不断地完成不同需求的页面开发，然而实际上只是大量的重复劳动，并没有那么多的成长。多了解其他人在做什么，怎么做，遇到困难的技术场景就去挑战它而不是退缩。对于大量的重复劳动去更多的思考共性，怎么样才能把自己从这些事情中解放出来，有更多的时间去解决更多业务上的痛点以及技术难点。
最后
写经历+思考有点累，明年年度总结还是流水账+吹牛逼吧（逃
重点：阿里云智能商业中台体验技术团队长期招 P6 及以上前端，有兴趣的欢迎勾搭，加我微信 answershuto 详聊或者简历发我邮箱： ranmo.cy@alibaba-inc.com。查看详情
年前面试，年后入职，美滋滋！！！
