简介： 思维方式直接决定了一个人在工作上的效能和产出。经验是个人对过往项目的总结和处理方式优化。今天的文章来自于阿里工程师梓骞，从大学第一次接触动态网页到现在的资深前端技术专家，他分享了那些人生中的“大事”，让我们看到他是如何一步步转变思维方式，积累经验，升级打怪。

 作者 | 梓骞

大家好，我在阿里的花名叫梓骞，现在负责业务平台的体验技术部，主营业务是阿里业务中台体系的多端解决方案，同时还负责集团前端几个基础设施：Fusion、ARMS/Retcode前端监控、BizCharts数据可视化图表方案、Node镜像和部分Node中间件等。

跟大家分享我过往的经历：

如这个路线图中所呈现的，我其实并不是一开始就做前端，用现在的话说属于全栈。工作之后从事过.Net开发和C++，其中C++可以算是有5、6年的开发经验，只不过整个过程都伴随业务前端的开发，直到在2012年因为业务需求专职从事前端开发工作。在整个过程中，有非常多的经历，成长其实也是伴随整个过程一点一滴的积累，仔细回忆下，可以分成几个阶段。这几个阶段，也有一些对我发展起到决定性作用或者转折的事情。

热情

2003年~2007年，我在大连读大学，加入了一个计算机社团，维护学校校园网以及另一个校园网站，虽然在之前就接触过HTML开发，做过一个个人主页(当时个人主页很流行，而且名字基本都叫××的家)，但在社团里是第一次接触到动态网页，才知道网站居然还有管理后台，之前以为是一个页面一个页面地复制出来的，也是至此就迷上web开发，从校园网站的内容编辑做起，再慢慢自学ASP开发，大一结束后已经可以独立负责一个站点的技术开发工作。

机缘巧合，大二刚开学的时候学校的物理实验室准备做一个选课系统，在学长的鼓励下我去接了这个项目开发，用了几周的时间完完全全由一个人开发完毕，不久就投入到学校运营，还记得是每周二中午实验室会开放下一周的实验课程，因为资源有限，大家一起去抢课程，当时用ASP+Access (是的，确实是Access当数据库) 在一台服务器上撑住了过千的并发，虽然慢但服务没垮，也没出现超卖的问题。现在想来，这不就是秒杀活动吗。这个项目做得还算成功，当时也通过这个项目认识了非常多的老师，这也直接促使后面承接了更多更大的项目，最重要的项目是交通部的一个内容发布系统，也是一个人花了两个月的时间完成，当时在社团的办公室里经常一个人写代码写一通宵，那个时候年轻，也乐此不疲，也没觉得累。

大学四年业余生活也是在不断的开发和各种实际项目中度的。大学毕业的时候粗略统计了 一下，各种项目加一起代码量大概在10W行左右。也是由于这些实际项目经验，在大四的时候找工作，面试官问的很多问题基本都是实际项目中遇到过的，所以也很顺利拿到了国内一家著名互联网公司的校招offer，也是我第一家服务的公司。

打破常规，积极沟通

毕业后直接去了第一家公司，在这家公司里，大家叫我的昵称「泡泡」。可能因为做了太多OA类系统的原因，也直接被分配到企业IT部，相当于阿里现在的企业智能事业部，对于毕业生，主要工作也就是开发各种审批流程。

随着开发的流程越来越多逐渐发现一些规律，有些审批流的代码几乎一致，只需要修改部分类名和关键信息即可。可能过去在大学开发许多项目的经历，有一个习惯一直保持到现在，那就是最受不了来一个页面做一个页面，如果出现重复性的劳动，我一定会想办法用工具、改进架构、自动化等手段让机器去做。所以当发现许多代码是重复的时候，就特别想改变重复性的coding工作，最开始是批量替换，后来找了个代码自动生成的工具，随着对所负责的系统架构越来越熟悉，逐渐改项目架构，每天下了也是在研究项目架构并自己写demo去验证，到年底总算可以实现对相似流程简单配置一下就可完成。

正当自己对结果很开心的时候，认为自己是打破常规，不仅能完成工作也能主动去改变现有研发模式，但人生中第一个考核就是「待改进」，相当于阿里的3.25，当时百思不得其解，跟主管聊过之后才发现自己存在几个严重的问题，比如目标只是完成工作，不关心业务和用户，也不关心用户体验，甚至一个表达用了多种交互形式；再比如，不关心业务质量，甚至bug直接在线修改，也出现过故障；最后，最严重的问题，遇到问题抱怨过多，比如抱怨自己依赖的组件有bug，抱怨基础设施不稳定等等，抱怨为什么方案总在变，一个词概括就是「学生思维」，比较自我总是站在自己的角度去看问题。

这次绩效，现在看也一直认为是一个转折点，自那以后基本停止抱怨，能够主动打开心扉去接受现状，去跟其他人沟通把自己的想法跟其他交流，主动去提出自己的改进方案，紧接着的一次考核，居然是A，相当于3.5+或者3.75-。现在想来很庆幸当时遇到一位负责的主管，如果是说保护毕业生在绩效上放过一马，或许再过半年当思维方式定型就改不过来了。

「泡泡出品，必属精品」

一年半以后自己转岗到业务部门，主要是C++，所以当时也是彻底从.Net技术栈切换到C++。依然保持打破常规、积极沟通，在一线繁忙的业务中完成一个又一个的项目，在业务部门的一个优势就是，可以告诉亲朋好友：“这个功能是我做的”，所以也特别关注业务，关注用户体验，而且当时公司的研发流程是：在提交测试前需要转体验，就是请产品经理体验一下研发人员开发的项目是否是自己想要的，功能是否有遗漏，体验好不好之类。

直到有一天，发生了一件我认为对我影响深远的事情。有一次照例转体验，不一会收到产品经理的回复，大概意思是，体验非常棒，泡泡做的简直可以打上「泡泡出品」这个品牌了。这句话，可能本是产品经理一句恭维的话，虽然产品经理经常恭维程序员，但说者无心听者有意，这不就是我一直所期望的吗，经我手的项目，就是质量过硬体验好，泡泡这个名字就是品牌。

也自那以后，我的对自己的要求就是提交测试后0 bug，用户体验就是一级棒，用户用起来感受就是“这就是我想要的”。为此，自己模拟各种使用环境自测每一行代码和异常处理，处理好每一个交互细节，比如对于动画延迟，不断去测试延迟100毫秒、200毫秒、300毫秒、400毫秒等参数，最后发现300毫秒是最自然的效果，于是把全站的延迟都调整到300毫秒，已达到全站所有同一个交互表达有统一的表现。 持续的投入总会有结果，后来部门期望提升研发流程的耗时，节省测试时间，试行对于简单功能或者开发质量高的同学可以免测发布，而我就是第一批被批准为免测发布的人，我开发的程序可以直接发布上线不需要测试，因为确实在数据中显示，我已经有很长时间没有被发现bug。

当然，在这背后也付出不少，除了有心去要求自己，技能也需要一点一滴去积累，也没啥捷径，计算机是一门实践的科学，就是多写代码。在我14年离开这家公司的时候，我的代码贡献量是排到小组前列，离开两年之后还有人告诉我，我的名字还排在前列。

个人经验到组织能力和产品能力

个人职业生涯另外一个转折点是在2012年，在之前都是C++是前端同时做，到了2012，随着移动设备的兴起，视频的播放从传统的flash过渡到HTML5，并且越来越重视播放体验和变现能力，所以业务的重心也开始向播放体验、广告等方面倾斜，于是我开始专职做前端，主要是从事以HTML5为核心的移动端视频播放和广告播放。 

HTML5播放并不是简单的使用video标签就可以解决的，这里面涉及到播放兼容性、播放质量跟踪、清晰度切换、防盗链、CDN、贴片广告、播放后推荐等因素，远不是各种教程里写的简单设置个video标签和src就可以解决的，所以也在实际项目中攻克了很多技术细节。

然而视频是互联网最基础的需求之一，越来越多的业务也需要嵌入视频，也需要去适配各种移动设备，前来咨询的人越来越多，我发现我有一半的时间都在帮各种业务解决播放器调用的问题，于是开始写了一个移动播放的白皮书，说明如何实现移动端播放。虽然文档能解决部分咨询的问题，但依然会有各种新的问题来咨询，后来想想，为什么我不把这些调用过程封装成一个JSSDK呢，把想法跟主管沟通后得到大力支持，就这样每天下班回家利用业余时间花了近1个月开发出了这个SDK，只需要传入简单几个参数就可以自动适配平台渲染出播放器，最初被公司新闻App引用，后来又被公司多个具有海量访问的App引用，直到我离职，这个SDK成为当时前端组最核心的工作之一，每天的调用量超过亿次。

时隔多年再回首这段经历，才知道无形中做了一件我们称之为“个人经验到产品能力”的事情，就是把自己在长期业务中积累的专家经验，以产品化的思路变成一个技术产品，让不具备对应经验的人也能很低门槛的使用现成的能力，达到经验的可复制，服务更多的业务。

2014年来到当时的阿里巴巴共享业务事业部，也就是我现在所属的业务平台事业部的前身，承载了阿里经济体电商核心，构建阿里巴巴商业操作系统，虽然现在支撑了阿里经济体众多的电商业务，但在当时接手了非常多的淘系业务，而且许多业务都是PC端，大量的页面依赖的Ajax接口返回结果才能正确渲染，然而我们并不知道接口的稳定性到底如何。做前端最尴尬的事情就在于，所有的错误都表现在前端，直观的感受就是前端不给力，进而影响到业务和用户。所以急需对接口稳定性做监测，过去个人是有这方面的经验，但寻找了阿里现存的体系都无法满足诉求，于是主动联合中间件团队发起了早期第一版的retcode监控平台(也就是现在阿里云前端监控产品ARMS的前身），同时配合几个新业务的上线，效果很明显，直接发现了多起线上问题，业务方也很认可，直接帮我们推荐给了其他团队，所以也逐渐开始有其他团队的同学介入。

所以对于Retcode，当时我们也面临一个选择，就是到底只小精力投入满足自己需求即可，还是开放出来给其他业务团队使用，因为我们当时根本就没有这么多人力和服务器预算，而且量变到质变，所要处理的数据量越来越大的时候，要投入的技术方案也会发生根本变化，对系统自身的稳定性要求也更高。后来的事情大家都知道了，我们选择了开放出来让大家都接入。我们考虑的原因是：

1. 有业务想接入，说明这个需求是真实存在的，Retcode在用户端根据真实体验的数据监测方式大家也是认可的；
2. 既然需求存在，即使不开放出来，其他业务也会自己做，那么算上重复投入的人力和机器成本，反而更浪费，而我们开放出来以后，形成规模效应成本反而更容易控制。 开放出来以后，其实以开始路也并不顺，开始服务不稳定，容量经常不够，数据不准确，丢数据，还需要解决权限控制等等，以及各个业务也会提出很多需求，功能也需要不断完善，整个过程也是非常的煎熬，当时给团队要求也是坚持一年，一定会有好的结果。一年之后，我们不仅打磨出了一款好的产品，还历练出多位在前端APM领域的人才，在全国诸多技术分享大会上也见到了他们的身影。

到了2016年，我们的业务形态是大量的ToB、ToE系统的开发，要适配多个BU的设计风格，技术体系上也在React趋势上行的阶段，急需一套打通设计到前端实现的UI域研发体系。经过一系列的调研和合作沟通，跟ICBU前端团队一起拍了合作的意向，并跟当时的国际UED的设计师一起孵化了Fusion体系。整个过程其实也是将多位设计师长期在项目中的设计分解经验和多位前端技术抽象的经验，通过技术产品化，把多位专家的优秀经验，从组织能力升级成产品能力。Fusion的能力提升，也是随着Fusion支持的业务场景越来越多，逐步将上层业务的需求和用法沉淀下来的，比如一开始是不具备国际化能力的，配置平台和文档也是全中文，这是在支持lazada业务之后才开始具备国际化的能力；一开始也没有信息无障碍能力，也是因为适配国际业务的法务要求才沉淀下来，一开始对这块也没太多经验，部分同学在业务中具备了个人经验之后，再将经验产品化。

主动补位，不给自己设限

因为过去的项目经历，本身自己算是全栈经历，所以一直认为前端不是因为我们用JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端。这个思想一直作为我从事前端岗位做决策的依据之一，只要认为是跟端相关，影响到用户，那就是我们的职责，或者是我们要去推动解决的。越是开创新战场的打仗团队，其实职责越不清晰。

印象最深的就是在lazada Voyager项目中，因为是开辟一个新的战场，时间紧任务重，许多人也是从其他团队抽调临时组建起来的，其实有挺多职责不确定的事情，没有说这是你的职责也没说这不是。遇到这类事情，判断的唯一依据就是，这是不是通过端去影响用户的，如果是，那就是自己的职责，那么剩下的就是兵来将挡水来土掩，排除万难解决问题就好，比如项目中出现过客户端人力不够的情况，那么考虑到业务进度，主动补位可以先用Weex或者H5先顶上，再比如埋点也是一个灰色地带，产品经理也很忙，那就直接主动拉着产品经理一起去梳理。表面看来，多做了一些事情短期没有任何的回报，甚至还额外加了很多班，但利他是最大的占便宜，在项目发布后整个团队受到的评价都是很正向。

关于现在和未来，当前主要工作是：

阿里电商操作系统前端解决方案；
设计中台体系建设 —— 服务阿里几千名设计师和几千名前端的设计提效、促进协同的设计体系；
承担在集团部分Node中间件、Node镜像等开发维护工作；
前端大学 —— 阿里经济体前端委员会人才发展方向；

其实，这几块工作里，只有第一项是我的kPI目标，而其他的比如第二个设计中台，我个人觉得这是建设商业操作系统UI域解决方案必须要强合作的事情，也由于自己过往在国际UED，对设计师的痛点也相对了解，自己也相信解决几千名设计师和几千名前端的协同合作效率，改变UI域的研发模式，一定会给集团甚至业界带来效率的飞跃，这也是自己长期所相信的相信，既然自己也觉得有价值，跟自己的主要KPI也有关联，那就去做。而其余的事情，其实基本不在自己的KPI里，但也是那句「Not Me，Who」，自己觉得有价值，这个事情也是需要去做的，那就去做好了。也没有给自己设置限制。

总结

兴趣是最好的老师，做一件事情首先是自己要有热情，如果只是当成一份工作，内心就很难让你全情投入；
认真做事能把事情做完，用心做事能把事情做好；
利他是最大的占便宜；
前端不是因为我们用JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端；
计算机是一门实践的科学，多动手是王道，知其然知其所以然；
协同是「两个人」的事，但协同成功是「一个人」的事，想要最终结果是成功，必须放下界限，向对方多走一步。
除了自己，没人能给你设限。
做自己认为对的事情，并坚持下来。

以上，是我从业前端这个岗位过往的经历和感悟，感谢阅读，共勉。