我在阿里云作前端

前言

今年是我毕业的第10个年头，半路出家作了前端，title一直是前端，你能够说我很专一，有时候也有些遗憾。一直以来，当别人问起你是作什么的，我说前端或者全栈，别人说：哦，作页面的啊！内心不免有些失落。前端是个资源型角色，在认知里对业务的理解深度不够，加上一般负责业务领域很广，比较难有积累和沉淀。若是你问一个毕业10年的JAVA老司机，他跟你谈的必定是大流量下的分布式架构，而前端可能仍是昨天茶余饭后讨论vue和react，或者是angular谁更强。如何突破，如何提供业务更多价值，前端们一直在苦苦探寻。网上不少文章，给人启发，但每一个人面对的环境，负责的业务不一样，不必定都适用。结合本身过去几年在阿里云的前端经验，也作个总结。

1.0版本-工具&团队

今年是我来阿里云的第五个年头了，从没有想过会在一个公司呆的如此之久，更没想过我能在一个岗位上沉淀四、5年。刚入职在阿里云控制台团队，主要负责云盾控制台、drds控制台等，开发过程当中发现大部分场景是「表格」、「表单」，为了不本身不断重复开发，封装了simpleForm以及控制台cli脚手架，能够作到新开发控制台一键敲定(这个脚手架直到去年还有人问我如何用……也是经久不衰)。这个时候也萌生了作个ide，可视化搭建UI视图，不过限于精力和当时团队的方向，且当时vscode还没今天这么流行，没有尝试，比较遗憾。不过作WebIDE这个点，算是在内心种下了。

后因为组织结构调整，我从控制台团队独立出来，负责当时的网站运营方向，开始比较艰难的从0-1组件团队过程。当时业务相对比较简单，主要是：阿里云官网以及官网的Nodejs、云市场业务。因为在控制台团队主要用的angularjs，感受上手成本比较大，在创建新团队，以及我本身能够选择的时候，React成了个人首选。当时vue还没成熟，其实能选的也只有react。新的技术体系，须要有配套的工程化体系，当时Def还处在1.0时期，为了稳定以及减小开发成本，很天然咱们在xef上作了插件式开发，结合本身业务特性，分装了响应的模板，以及定制了开发周期。后因为xef1.0升级2.0，致使咱们工具的不稳定，且改动很是大，逐步将咱们的工程化体系独立，这就有了后续的DBL。我跟老板作汇报时，老板以为这名字上不了大雅之堂，还硬是憋了个比较有内涵的名字——实在很差记，我如今都记不起来了。这个阶段，咱们作了不少技术上的尝试，团队成员都很是苦逼，也很是有激情。团队基础设施建设，咱们一直在优化，随着Dawn的基于中间件式的pipeline方式设计，能够说是将工程化作到一个比较高的高度，将来无论是webpack升级到多少，或者新的打包工具出现，对咱们来讲影响都比较小。面向将来的模式，让咱们只须要修改内核，使用者无感知。新的工程化方案也积极跟阿里云其余团队沟通和交流，以前跟风驰和释然也达成一致意见做为阿里云统一构建工具推动，不过落地的不是很好。同时，新的方案也彻底遵循集团的标准，跟淘宝阿大团队无缝对接。另外还有一个好处是：dawn不局限在react，你可使用任何框架；dawn不局限在redux，你可使用任何你喜欢的数据管理，实际上咱们本身有用mota，mobx，graphql-apollo等等。

讲完工程化，其实应该讲讲组件化，这是个没法回避的问题，但这对咱们来讲也是个艰难的过程。15年的时候，咱们用过antd（已开源），可是在上层作了一层业务封装；后来fusion开始盛行，在跟ued沟通后，考虑到集团统一，用了一段时间的fusion（已开源）；最后咱们仍是选择了自建组件库，这是一个很无奈的举动。具体细节不表，其中一个重要缘由是咱们的前台业务须要「阿里云本身的设计元素」，在通过团队很长时间的建设，APS组件库已经做为团队组建库的基础，在其之上构建了业务组件，并在之上构建了业务解决方案。

除了折腾传统前端领域，也尝试作了不少跨栈的事情。在我所负责的业务中，因为「端」业务的确实，咱们更多的是偏「全栈」。前端同窗作全栈，讲实话是不行的——绝大部分前端同窗在架构、运维部署方面仍是经验偏少，考虑更多的是跟展示层相关。在全栈路径上，因为咱们负责的是核心交易链路，咱们没有用你们熟悉的nodejs，而选择跟后端同样的语言——Java。作这个决策，实际上是挺困难的，也是有故事的。原先有个系统，前端同窗用Nodejs写的，但因为业务很是复杂，加上前端一直是个资源瓶颈的角色，一我的干三我的的活，因此这个同窗最后搞不定，离职了。这么个系统就变成了后端想接没法接，前端「没人力」接的情况，很是尴尬。从那之后，业务系统中就决定了直接使用Java。

在全栈路上，咱们主要有两个策略：

• 大前端下本身写部分业务的Java
• 利用serverless经过代理统一配置化转

大前端写Java，阿里云其实很是多的前端都已经具有了这个能力，我本身也有独立开发几个系统从0-1上线，分布式部署且支持国际化的经历。作了一段时间后发现，其实效率上还好，并无传说中nodejs比Java要高效不少的体感.

利用serverless经过代理统一配置化转，有段时间看社区有部分人提到Graphql，对此产生了兴趣，就顺便了解了下，经过代理的方式能够将后端数据转换成前端须要的格式，很是吸引人，也就一会儿扎进去。我本身也同时作了Nodejs的版本给团队同窗普及，同时作了Java版本的demo给后端普及。同时了解到b2b的Mbox平台跟咱们想要的能力比较像，找过他们给咱们分享，但因为业务系统整个搭建在他们平台有必定得风险，因而决定了自建代理平台，这也是「云查询」平台的背景。云查询主要是战锋主导并推动落地的，在集团内取得了不错的影响力，不少BU不少部门去作过度享。在业务上，经过云查询，咱们实现了不用管应用的运维和部署，实现业务逻辑和接口的转换，并自动扩容。尤为是营销体系，在元策&隐天和战锋得协同下，取得了比较大的效率提高，并支持了阿里云去年的双十一。

云查询通过一段比较长时间的发展，咱们已经逐步将它做为基础能力下沉，在云查询的serverless之上长出了不一样的「轻应用」，以支持不一样的垂直业务场景。好比：可视化搭建领域「页橱」、基于权限&角色的中后台解决方案「Flex」等；

还记得我以前说过5年前我想作WebIde，没有开始；2年前，看到其余云厂商有WebIDE，咱们因为业务压力，业务压力没有搞成；今年咱们总算是有一点启动，已经和appStudio的同窗在共建，基于appStudio基础之上把咱们的dawn、云查询作打通，作云端集成化、一站式的研发体验。

经过以上的技术基础建设，已经为咱们构建了很好的基础基础。业务布局对应着团队、组织的建设。过去几年，团队从0-1建设，到目前xx个在岗同窗，造成了4个梯队，三个3业务方向&一个技术架构方向，一路走来，感受带团管理水很深，不少时候不是说你带的人越多越好，最近看到一本书提到一个词「情感成熟」，这个很是重要。一个技术好，作业务的好手未必能管理好团队，在不一样阶段须要适应不一样角色的要求，最重要的是时刻保持忧患意识、保持持续学习。在团队建设时，须要重点区分manager和leader，尤为是业务团队咱们更但愿成为leader，去带着作业务，而不只仅是作绩效管理。

2.0，也就是过去一年，咱们在业务思惟指导下，owner了部分业务，并利用横向的技术打通、横向的业务思惟，取到了一些成果，接下来进入2.0

2.0业务思惟-以横向视角推动业务赋能

咱们一般把组织中的人分为：一字型、|字型、T字型、+字型。前端正好是—字型团队，负责的业务很是广，而前端又是个很是稀缺的岗位，招聘很困难，因此盘子越大资源瓶颈越明显。「一字型」角色团队，典型的问题就是对业务的深度理解不够，单纯从技术层面去作营销的搭建、中后台的可视化，结果都不尽如人意。这么提及来，可能你以为无法往下看了，天花板在那里，如何突破其实并无太多可参考的例子。我写这篇总结，正是有些这样的感悟，但愿给你们作一些输入，帮助你们去思考。

「一字型」虽然从业务上看咱们的深度不够，但从专业技能看咱们是标准的「|字型」。前端通过这10来年的发展，语言、框架、工具已经逐步趋于稳定，各类端的性能也愈来愈流畅，生态很是活跃，任何你碰到的困难相信社区都已经有比较成熟的方案。前端生态快速发展的10年，也验证了咱们这些人有着很是强大的学习能力，7天一个框架、3天一个数据库估计都不是太大难事(略夸张，但表达的是这么个意思)。前端直接对接客户，对客户体验的敏感、对流程数据化的敏感、对业务逻辑流程的感知，都是咱们生存的根，也是咱们独一无二的能力，这个根咱们不能丢。

有句话叫：饱暖思淫欲，不太恰当，姑且一比。在前端纵深领域的深耕，让咱们成为了「紧缺资源」，随着工具的完善，前端们也更但愿利用技术为业务赋能。如何赋能？挡在咱们面前的是「意识」。在营销中，认知、需求、品牌、品类、价格五个要素中，「认知」最为重要。好比阿里是作电商的、腾讯是作社交的、百度是作搜索的，bat在本身主营业务范畴不断布局，构建了庞大的生态，作过不少尝试，但看起来最终仍是围绕自己的基因作生态投资成功率要高一些。那咱们想要业务赋能，瓶颈就在于「你个切页面」也要赋能吗？好好作好体验、提效很差吗？我认为「体验、提效」这是前端最核心的能力，也是毕生都努力要实现的目标，坦白讲咱们无法立刻解决资源瓶颈问题，毕竟如今毕业生都在应聘算法、ai、人工智能；咱们也没办法搞一轮体验提高计划；这是个很漫长的过程。但若是咱们能以业务的角度出发，去发现问题进而辅助以技术手段解决，并沉淀平台，应对将来变幻无穷的需求，可能更为实际一些。作为团队的TL，除了在专业上给与同窗「|」型的能力纵深，也更但愿带着团队同窗得到更多业务体感。离开业务谈技术、谈中台都是空中楼阁；离开业务谈前端，注定只能是重复造轮子，而这种低水平的重复正在发生，且可能会持续好久。

在很长一段时间里，我都试图把咱们「一字型」业务广度作个抽象和融合，但愿把「点状」造成「线」，进而造成总体「面」解决方案。我所负责的业务中，主要有4个大方向：

• 官网&营销—for长尾
• 商业化流程后台-for 小二
• 核心售卖流程—核心能力层
• 销售、合做伙伴

官网&营销：主要包含获客、激活、转换、留存几个节点，构建高效的「人」、「货」、「场」。很长一段时间里，阿里云的内容维护、营销大促都是基于集团CMS来的。传统大促会场、卡片的方式，前端挖坑后运营编辑内容，而阿里云的「商品」跟淘系有着比较大的差异，另外咱们也没有招商、选品的体系，致使这种简单人肉运行的大促方式存在不少弊端，好比不高效、不复用、不能作个性化、数据流程监控力度不够精细等。此外「投放」能力的建设还不够，没有办法作到精细化的人群作精准的营销内容投放。为了解决这些问题，去年开始，由前端团队和pd一块儿推动完善的营销体系建设：

• 在原有商品的基础上，构建了「营销商品」的概念。更抽象的「货」，且可视化在线配置直接拉取了实时价格和库存。经过咱们1.0工具建设的dawn，打通开发流程，使得整个开发链路一致，成本更低。可抽象的货匹配上专门为货打造的UI视图，造成场景能力沉淀。
• 构建ACE(Alibaba Cloud Experience)架构体系，打通搭建体系，经过技术降级打通各种「场」，更好的承载好营销商品的投放。
• 经过全链路场景的曝光，点击，转化，以及最终成交的商品信息等数据的积累，生成用户画像，提供内容场景化方案（在不一样场景中精确得向用户展现商品或信息)完善「人」的定位。

商业化商品配置：上面提到「营销商品」时提到「基础商品」。目前阿里云基础商品主要分为：「公有云商品」和「技术输出型」。过去很长一段时间咱们偏公有云的能力建设，今年年初才开始逐步融入专有云体系。在商业化系统中，咱们的小二须要配置售卖规则、价格，须要定义商品模型；同时复杂的规格之间的约束，异常复杂。如何提升商业化的输入和输出的强体验，咱们还有很长的路要走。结合今年的专有云项目，从模板的方式出发，将一类产品作个聚合，简化商品模型配置的步骤，大大提升了配置效率，提升体验。

销售&合做伙伴：15年刚开始组建团队(这里指的都是前端团队，不是业务团队)，15年-18.3月大部门的核心kpi是营收、是首购用户数，主打的是中长尾客户，得到了很是高速的市场增加。后来团队cover范围不断扩大，也负责销售&合做伙伴体系，围绕着「市场营销」、「商机培育」、「商机转化」、「合同履约」构建了咱们本身的销售crm系统。toC的业务一般比较好理解，毕竟咱们也是c的一员。这段toB的经历，结合业务一号位的培训班，让了解到销售系统的核心，除了工具，最想要的是解决方案，是产品能力的丰富。

大概介绍了各个方向的业务，回到咱们讨论的主题来——借助横向优点，整合资源&架构提供业务赋能。为了分析他们之间的共性，咱们通过不少次的讨论，终于汇聚获得咱们的业务流程大图(对外脱敏后的示意图)：

从这个流程大图中，各个分支最后都须要依赖「售卖能力」，这个售卖能力

• 表如今营销中是「弹窗buy(减小跳出，直接购买)」、购物车(多产品交叉购买、数据算法推荐)、套餐(多产品打包优惠售卖)、提货券(下单和生产分离的售卖能力)；
• 表如今销售链路中是「产品配置清单」、「采购单」、「CBM提供给大客户的CTO价格计算器」
• 表如今商品商业化链路中是「模板化」配置清单能力

在一大团子中找到业务的共性「售卖能力」，在经历一段时间比较耗资源、耗时的烟囱式开发方式后，抽象出了售卖的核心支持层——紫金阙。这一层，咱们定位为业务中台，偏前端层面，也是大前端的领域范畴。惟一须要指出的是，咱们用的是Java，没有用nodejs，无其余差异。最后架构以下(脱敏，细节忽略)：

新的架构模式下，咱们减小了大量的先后端沟通，好比「分销采购市场」以传统开发方式须要1-2个月，咱们2周就搞定了。新的架构模式，在可预见的将来，能够很好的支持各类营销新玩法，也能够支持销售和合做伙伴的『解决方案』。

我想说的是，若是没有咱们全量业务的横向视角，咱们的抽象方案不会这么通用，这是前端团队的优点。若是没有大前端稳定的技术生态，咱们也没机会去作业务赋能。这才是前端的将来，利用横向优点整合，结合某个领域作深作透，造成垂直深度，为业务提供价值，也让咱们的技术方案「有的放矢」。前端常常是围绕一个点作需求，获得工具，但没法提供解决方案，由于没有业务属性；惟有结合业务特性，作好沉淀，工具变成平台才能释放更大价值。

3.0探索以技术能力为业务提供增值

「云计算」核心是解决企业成本的问题，用低成本得到超强的计算、存储能力，得到高并发下弹性扩容的能力。云计算提出了不少概念：IAAS、PAAS、SAAS。。。相对前端角色来说，体感并非很强。可是BAAS的出现，让前端眼前一亮。试下想，原先咱们须要大量后台开发的应用，逐步都沉淀成领域能力，提供baas服务给前端调用，前端不再用考虑部署、运维，只关心业务代码，想一想也是心动。目前市面上提供相似服务的公司不少，有专门作后台数据存储的如Leancloud、有作数据分析的、有作消息推送的等。因此，Baas会是前端的春天吗？这个拭目以待。

扯了理想，咱们也说说现状。目前阿里云大概是Buy In Aliyun，咱们售卖的是IAAS层的资源，用户核心的业务流程仍是基于本身的研发体系。在前端这个纵深领域内，基于云打造「云端一站式研发流程」，将企业前端变成：Work In Aliyun or Dev In Aliyun。经过对企业前端生命周期的分解，经过WebIDE来承载整个流程：

1. 将建立关联阿里云的code

2.阿里云前端构建工具dawn做为基础构建能力，可定制化团队构建的中间件(webpack、lint、server、mock等)、构建stage(init、dev、test、publish)；基于工程化化能力提供统一的规范，提供各类不一样应用框架的初始化模板。

3.代码点击发布后，自动编译，并发布到cdn。

在此基础流程之上，咱们提供serverless相关能力，经过调用BaaS领域服务能力，以及FaaS网关触发能力，实际上咱们能够彻底一站式，且是前端主导的应用开发。

还记得我前面提到咱们的serverless应用「云查询」，这一层咱们逐步进行能力下沉，变成serverless基础能力。各公司几乎都有营销搭建体系，过去搭建的玩法不够多样，主要依托cms能力自行开发，随着如今各类「端」能力的延伸、多样性化，营销搭建也变得愈来愈复杂。而咱们基于「云查询」之上沉淀出的「页橱」搭建体系，彻底能够借助「云端一站式研发流程」提供很好的SAAS化服务。这是咱们的优点，「云端前端解决方案」也只有咱们适合作这个，这里只列举了其中一个场景，相似的机会还有不少。

整体感受，一云多端借助serverless前端的春天已然来临。抓住咱们核心的竞争力，并同时发现业务中的问题，跨端推动解决，这是最好的出路。你问我作什么的，我…… 我就是阿里云CPO（首席页面仔啊）

ps：阿里云智能业务中台&阿里通讯招P6-P8前端，欢迎来撩。base可北京可杭州，杭州工位在美丽的西溪园区哦。旁边挨着的都是UED妹子&测试妹子。xiaoming.dxm@alibaba-inc.com

原文连接 本文为云栖社区原创内容，未经容许不得转载。