我的前端成长之路：中医药大学毕业的业务女前端修炼之路

大家好，我是风月，2014年二进宫进入阿里，目前是业务平台体验技术数据服务前端团队负责人，负责 BizCharts 横向建设以及财鲸数据业务支撑。本次分享我将回顾作为业务前端从前端工程转型到数据可视化过程中的心路历程。

前端工程师的修炼没有捷径，踏踏实实的通过一个个项目的实践来升级打怪实现进阶；本文仅分享自己11年的前端生涯，探讨一直在业务中的技术人的成长之路，也复盘再认识下自己，每个节点我遇到的问题和我的选择，过程中聊聊走过的弯路希望能让大家少走弯路就达到我的目的了，不说教，不带货。

技术 TL 进阶金字塔

在我十一年的职业生涯中，以一个阿里的BU为单位，从推动解决业务问题的角度，我基于自己有限的观察总结了需要修炼的6个层次仅供大家参考。

第1层是个人专业技术能力的修炼：

• 我们工程师从校招开始进入阿里就被安排通过项目开发来训练基础编程能力。一般工作三年，就能够胜任编程岗位工作。编程基础好，成长快的小伙伴1～2年就可以实现专业能力的储备。编程是一门需要动手实践的工种，且在阿里这样的大型互联网公司，业务复杂度不断攀升，一万小时定律被验证是成立的，修炼后就可以在编程上辅导新人实现技术攻坚，这个阶段最重要的事情就是做加法，尝试更多的可能性，不要过早为自己定型技术细分领域，为后面在前端细分领域的选择上打好实践基础；
• 前端专业能力三板斧：前端工程、性能优化、质量保障
• 影响力：该阶段更多的是高执行能力，技术攻坚为主，解决点的问题，对项目的成败有一定影响，但不起决定作用；

第2层是人际沟通能力的修炼：

• 在阿里的研发工作中，不可避免需要与上下游的合作伙伴共同作战完成一个中小型项目（项目组成员10人以内）；此时修炼的是PM能力，能够通过对业务的理解识别到业务的痛点和项目的风险，给出优先级事项的判断，并协同和推动项目组一起解决风险，保障项目的进度；
• 既有专业能力又有人际协作效能，可以独当一面；
• 专业层面：经过第1层的实践，开始系统了解技术细分领域，同时基于自己所处的业务和团队情况，作出选择，比如node全栈、数据可视化、中后台、多媒体、3D渲染等细分基础技术；
• 影响力：对项目的交付质量能起到决定性的作用，项目主力核心；

第3层是组建团队&架构能力：

• 要求我们具备管理、计划、组织、协调、目标管理、激励、反馈、辅导、招聘、评估绩效等等能力，以便带领他人完成团队目标。具备可以迅速组建新团队或接管已有团队，能够很好的带团队、带项目，具备因人而异解释工作目标的能力，能用团队目标统合团队成员共同实现目标。这一层的修炼难度和挑战远远大于前面2层，因为技术相对是可控的，而人的管理非常复杂，且投入这一层修炼精力消耗较大，同时也要继续技术专业上修炼架构能力与保持编程能力；
• 专业层面：在第2层选择的基础上，细分技术领域上的深度实践，沉淀专家领域能力；
• 影响力：能够判断团队所负责业务的痛点，并能结合团队角度给出对应的技术方案，工作会影响到大部门的业绩；
• 观察样本：最丰富的样本来源，身边有不少优秀的案例，我自己已经修炼过几年的时间，还有很大的提升空间；

第4层跨职能协作能力：

• 修炼到这层，应当具备多线程工作的能力，可以带领几个核心骨干或初级TL，统管多个团队和项目，同时，也能够跨职能沟通，跳出前端的岗位视角，更多元化的思考问题，比如能够很好的协调后端、测试、算法、HR、运营、PD、PMO等各个团队一起工作。
• 专业层面：第3层的基础上，还能够具备一定的行业见解；
• 观察样本：深入业务合作过的资深TL们，我自己也是刚开始投入这个层次修炼，视野很重要；

第5层组织发展能力：

• 修炼到这层的人，了解企业的各个职能是如何工作的，能够为BU的扩张做支撑，哪个部门该加人，哪个部分该减人，都应该心中有数。此时的头衔，往往是部门总监，能够给出组织架构上的设计建议并推动落实。
• 专业层面：这个层面已经不单纯讲专业，更多是深度结合细分行业的业务做技术决策和业务决策，产生业务价值；
• 观察样本：我的主管

第6层战略眼光：

• 此时的身份往往已经是BU Head 或 BG Head了，为公司的未来发展负责，判断未来趋势，规划战略方向，组织效能提升，人才战略，产品战略，都是需要关心的问题。
• 观察样本：业务平台的大家长 @若海(eric.yug)和 CFO产技部的大家长 ；

我走过的弯路

弯路1、 2011-2014年间出走阿里去当技术TL，发现榨干自己，欲速则不达

2009年，我从浙江中医药大学计算机专业毕业，和CS强势专业的大学还是存在差距的，学长学姐也没有给出参考模版，一番分析后，不认命的我还是决定继续走前端工程师路线，一开始就很有自知之明，不怕从小公司做起。我大一就开始抓紧机会在计算机学院的创业园里开发学院网站以及大四全年出去实习来积累研发实战经验。幸运的是，几经周折如愿以偿P4入职阿里做前端，可能面试官看中我的不放弃，能否活下来靠自己了。

2009-2011年是我的第一份正式的工作，这阶段我主要负责阿里妈妈淘宝客的前端开发工作，主要技术栈是类库YUI，让我学会了模块化开发的前端工程思维。当时同团队的师兄们已经在实践应用backbone，尝试开发单页，还有一个骨灰级的大神 @李牧 在团队中坐镇，相对而言，对我这个菜鸟来说，09年就接触到了前端届的MVC，学习机会很多，技术氛围也不错；

2011年，本该珍惜来之不易工作机会的我，却因一点小插曲（毕业不久怀孕生娃拿了阿里职业生涯中的1）作出了看其他机会的冲动想法，同时被外部的创业公司以薪资double和技术TL岗所吸引，就这样离开了阿里。创业这一年日日生存在生死线上，资金紧张、融资失败、1小时裁员、互相鼓励、迷茫、解散，从激情满满入职到失望离开，至今历历在目。创业这一年学到的不是技术精进，而是血泪教训，意识到我正在偏离前端技术专家这条主航道，过早被眼前的薪资和TL岗位所吸引，忽视了欲速则不达的道理，我真正需要的是一个稳定长期发展的工作机会，不能短视到只看眼前利益。

2011-2012年，这阶段我的技术栈是seajs、jquery，关键词是模块加载、类库、轻量、ftp上传部署；

2012年，我顺利入职了腾讯（杭州），负责应用宝PC端的Web前端开发，两年后作为预备Web前端TL参加了潜龙培训，一切都在往好的方向进行中。但是，2014年初腾讯杭州分部突然被通知要求将应用宝PC端的业务从杭州迁移回深圳总部，杭州研发人员要么选择base深圳，要么在杭州从头再次孵化新业务，且此时腾讯总部也在大面积的收缩业务，从自研转变为投资合作伙伴。作为杭州土著家庭的我，要想继续我的技术专家路线，只能选择离开，找到一个真正足够大的互联网平台，能够支撑我长期发展。

2012-2014年，这阶段我的技术栈是Angular，MVVM、单页、shadow dom、框架、编译、CDN、动静分离等关键词；

痛定思痛，2014年04月28日，选择在生日这一天二进宫阿里，代表我的新生，从看似光鲜的TL岗重新回到一线开发工作，且暗暗下决心，这一次绝不会主动离开阿里，也不转岗，坚持到底活下来。此时二进宫的我已经工作五年，现在想起来特别感谢这一年没有层级和年龄的限制，让我这个浪子可以有机会回头。考虑离开阿里的同学一定慎重思考未来二进宫阿里是否还有机会，千万不要草率作出决定，可以参考我的血泪史。

2015-～，这个阶段我一路写过全栈node、移动端zepto、React，阿里统一以React作为底层技术栈，内部紧密共建React生态，toB研发模式逐渐形成，D2C（design to code）、webIDE、搭建发展如火如荼，数据可视化也正式被阿里加入前端招聘细分子方向，影响着前端从业人员努力的方向，并且不少阿里优秀的库对外开源回馈社区。这个阶段是最百花齐放的时刻，也是无形中在推动你成长，不要忽视环境的力量；

11年里前端技术栈发生着剧烈的变化，前端的职能边界一直在延伸。阿里非常鼓励我们在技术产品化上有更多的尝试，在阿里已有的平台上，独立从前至后完成一个专业的产品完全不是问题，就看你是否限制了自己，当然牺牲业余时间学习不可避免，我自己想的很清楚我会得到什么，失去什么，未来自己把控。

感悟：功利心是大忌，长远职业生涯考虑，发展才是硬道理，面包会有的

冲动是魔鬼，工程师在打怪升级的过程中，会遇到非常多的“意外”面临选择，比如失恋、迷茫、怕累、家庭、没信心、与主管意见不合、晋升失败、被打3.25、创业吸引、薪资吸引等等原因，无可厚非。但我更想说的是，想清楚自己真正想要的是什么？如果确定是技术专家路线，那就有自己的坚持，职场上的玻璃心基本上不适合长期发展，大概率“出局“。尤其是像阿里这样的高速发展的互联网公司，外部环境的剧烈变化必然引起内部的变化，一线的开发要有感知，但一般影响没那么大，专注做好自己的本职工作更重要；

正视3.25，从我个人了解的，大部分有三种情况。第一种是与该层级要求的能力有距离，如刚入职的新人不适应新环境，或者刚晋升到新层级的老人处在迷茫期；第二种是工作方式出现问题，如只会埋头苦干纯执行没有自己的深入思考；第三种是因身体原因，如生病修养一段时间，或孕期需要更多休息等特殊情况；前两种情况都可以通过努力来解决。3.25只是代表当前这个阶段，并不代表一年后两年后的你，成长需要看的更长远。至少我认识的发展不错的同事大部分都有被打3.25的经历，包括我自己，第二年逆袭3.75和晋升的大有人在，也包括我自己；更关键的是，主管的理由是不是更多关注在你的成长上，有没有看到自己的成长。

弯路2、2016-2017年业务量大，需要我更多投入修炼组建团队能力，代码量少，一度迷茫，差点失去信心考虑转型PD

2016年初，感谢主管 @梓骞 信任我，让我承担商家业务的前端TL，此时此刻的我，一方面要熟悉新接手的业务，一方面要修炼组建团队的能力，同时承担PM的工作。这一年下来，业务做起来了，团队建起来了，而我自己的发展呢？精力被分配，代码量少了，编程能力生疏了，开始迷茫，技术TL到底该不该写代码？是否只有我并发能力不行？只有我不适合当前端工程师？

我甚至主动的约我的主管 @梓骞 探讨我转型PD的可行性，认真的讲我对自己优劣势的分析。主管没表态，告诉我迷茫是好事，说明我在思考，对于我的想法不拒绝也不肯定，只是让我自己去尝试后再做决定，但前提是不能影响当前的本职工作，且明确的告知我技术TL必须写代码，而且是核心的代码，无论有多忙，都要保持住技术敏感度，熟悉当前的研发体系，对研发痛点有体感，再结合业务痛点才能作出更正确的判断和技术决策，否则面临的就是职业生涯的天花板甚至被阿里淘汰。

经过主管一番的指点迷津，了解到技术TL参与研发的目标后，我开始思考怎么选择项目来确保ROI，做好时间管理，而不是事事参与后精疲力竭还拿不到结果。此刻再回到业务本身的痛点，贴着业务打是最稳妥的方式，大数据客户运营平台最大的痛点就是可视分析的高效表达，且鉴于之前在ARMS监控平台中积累的图表开发经验，我发现自己对数据分析场景下的数据可视化有浓厚的兴趣，可以先从这里入手深入了解一下体系。短短几个月的探索，奠定了我后来几年为之奋斗的细分技术领域方向-数据可视化。

感悟：在业务痛点中发现机会，方向对了就不怕远，坚持就是胜利

现在回想，职业生涯中出现迷茫不可避免，是很常见的事情，主动找主管沟通是很明智的选择，可以更快走出迷茫期，避免陷入误区作出不成熟的决定。比如在TL初期很多同学都会遇到是否坚持写代码的疑惑，时间管理的疑惑，专业发展的疑惑。

深耕前端细分领域-数据可视化

在入行之前，我和大家一样以为只是简单的使用图表库，会API调用，能渲染出来折柱饼就行，实际上数据可视化这个方向别有洞天：

• 往业务垂直领域走，数据本质就是业务，就会存在业务垂直领域的问题，基于我对业务领域中的业务深度的理解，对数据量级、客户群体、核心业务指标、数据计算口径模型、数据流的链路等了如指掌，才能给出合适的技术方案，只有贴着业务做，才能作出业绩；再从成长角度来说，我在做业务的过程中，会一直思考我能沉淀什么可以被其他项目复用，差异就在于体系化能力是否实体化了。我自己选择的也正是这条路，主要是考虑到阿里当前的缺口，即使当前晋升体系还没有认可，但我坚信这是正确的方式。
• 往上层通用平台应用走，更多是构建可视分析系统应用，如DataV、FBI、DI、财税大脑等，需要我们对业务全链路有了解，熟悉完整的数据采集、清洗、提取转换加载（ETL）过程，可以利用工具完成数据建模，比如ODPS平台。如需继续深入做架构，还需要了解大数据处理（Hadoop / Hive / Spark等）相关开发经验，数据技术能力综合全面，才能对大数据的性能优化方案了如指掌，避免视角片面；
• 往可视化表达这一层走，统计图vs关系图vs地理空间可视化也是截然不同，业务差异很大。
• 往底层渲染走，一般是解决大数据的渲染性能问题或者图形渲染兼容领域，需要了解客户端、服务器端、Node端、移动端设备等多个端的SVG和Canvas的兼容性等，底层的性能瓶颈问题等；
• 往2D还是3D走，也是天然之别，2D更多用于分析场景，而3D应用在大屏和互动领域，技术栈为webGL、threejs等；

同学看到这里，不禁又问？那前端工程能力是不是没有要求，我只会做渲染实现绚丽的大屏？又是一个大大的误区，前端工程永远是Base能力，没有这个基础，基本可以不谈其他的，因为阿里的业务是一个大工程，而受限于你的技术栈不全，你能发挥实力的业务少之又少，谈何独当一面？因此大部分新人入职后，都会优先开始工程能力的训练，存活下来是第一要事。我自身能够顺利转型到数据可视化领域，也是依赖之前积累的工程基础；

感悟：机会总是给有准备的人，保持热情，坚持（死扛）领域深耕

我自己的经历是，刚开始是2017年初从商家业务的痛点入手，先重点做统计图，在作出bizcharts的原型并且应用到业务中后，和AntV建立深度的合作，基于G2沉淀出BizCharts赋能给集团，后又开源反哺给社会，这个过程中也深度参与前端委员会数据可视化小组，希望能贡献自己的一份力量。过程中牺牲了很多我自己的业余时间，比如参与答疑、参与文档优化和demo编写，确实很辛苦，但是我自己乐此不疲，因为过程中我了解到很多用户的真实诉求还有真实的业务用例，这对于我判断bizcharts的发展是很有帮助的，也逐渐清晰下一步应该怎么做。

后随着自己对数据可视化的理解加深，自己能Cover的业务机会也越来越多，2018年开始组建专业的数据可视化团队支撑业务平台的数据服务和大财鲸业务（阿里大财务中台），现在重点投入精力做财务行业领域的可视分析系统和ToB企业级工程解决方案。会一直深耕下去，踏踏实实的，一步一个脚印，稳扎稳打，一起加油。

修炼的本质

感悟：不惧怕失败，深耕绝不是一蹴而就，不积跬步，无以至千里

之前有同学问我：为什么我选的是数据可视化这个细分方向？理由如下：

• 业务痛点需要是第一优先级，这是我必须要完成的，能够解决业务问题的技术能力，就是好的技术能力，并不一定都必须是技术深度；
• 在2016年，进入DT时代，阿里数据业务化和业务数据化已经如火如荼，一片蓝海。阿里本质上是一家大数据公司，亟待专业的同学加入挖掘金矿，搭上顺风车，会比逆风而行更容易成长；
• 数据技术足够深足够厚，看得见的长期发展，且业务中多次的实践，让我很感兴趣，愿意为之倾注我所有的心力、脑力、体力，来提升我个人的能力；
• 积极主动历练自己和团队，多做功课，拿到技术圈子的门票不难，大家都比较“简单粗暴”非常愿意伸出援手，关键是要想清楚长期合力共赢的点是什么？技术壁垒的建立（业务诉求进入深水区）？大团队的技术组合拳？哪些你做？哪些合作伙伴做？

过程中我也是从一次次的业务中实践和摸索，在我看不清的地方，就跨出去先试试水，没有人一开始就知道所有，围绕着数据领域的业务一步步的做，一点点的积累，前期还看不到自己的成长，但是在坚持两年后，突然有一天发现自己有系统性的观点，可以和 @宁朗 @御术 等数据可视化领域的前辈，在一起平等探讨业务发展问题和技术建设的问题了，其实就是日积月累的经验让我从量变到质变了，一万个小时的定律至少在我这里是准的，失败并不可怕，可怕的是还没开始就放弃了；

我的主管 @梓骞 经常会讲，阿里很多小二比我们聪明，却还比我们更努力，我们还有什么借口说是天赋的问题。虽然聪明人很多，但不缺有想法的，更缺的是实实在在落地做实事的；内网ATA有很多非常高质量的前辈体系化的经验总结，非常宝贵，能够扩大技术视野，非常适合在碎片的时间里充电。

最后总结

心态要摆正，成长是自己的事，职场那么长，长达三十年，为什么我要跟面子过不去，老拿自己去和身边的同学比，非要去死磕层级，累不累？坚定我当前做的事是不是一件正确的事情，是不是解决了业务痛点，在当下，我的核心竞争力是什么？成长真要有什么灵丹妙药的话，可能是我的主管 @梓骞 一直以来的思维方式是怎么通过技术产品化等工作，提升团队的运转效率，那就可以做更多新的事情，自然而然的就成长了，这个思维方式对我影响很深，至少经过目前为止的验证还是成立的！一年可能看不到成果，需要三年～五年；

在经历千辛万苦之后，我幸运的晋升到了P8，你以为终于可以松一口气好好休息一下，其实是不存在的，因为你面临的是新层级的期望和要求，讲人话就是距离3.25很近甚至淘汰。说好的不可替代呢？真相是在工程世界里没有银弹，也就是不存在不可替代性的人，连马爸爸离开阿里，阿里也能正常运转。但技术领域研究越深入，权威度越高，替代成本就越高，一定程度上可以形成核心竞争力。阿里的舞台很大，身边的学习对象很多，立志做一个懂商业的数据可视化专业人士，打深、打穿、打透，新的征程，重新出发，努力踏上数据可视化领域的新阶梯。

作者 | 风月

原文链接

本文为阿里云原创内容，未经允许不得转载。