阿里云老用户l3-L4的免费福利邀请码,求土豪赐一个呢!!

刚刚体验阿里云不久 就发现阿里云的活动!!~ 新用户可通过老会员分享或定向渠道分享给新用户的邀请码参与免费套餐活动, 求一个阿里云的免费套餐邀请码 跪谢各位土豪大大~...

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

讲完工程化其实应该讲讲组件化，这是个无法回避的问题泹这对我们来说也是个艰难的过程。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 小二

核心售卖流程—核心能力层

官网&营销：主要包含获客、激活、转换、留存几个节点，构建高效的「人」、「货」、「场」很长一段时间里，阿里云的内容维護、营销大促都是基于集团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化服务。这是我们的优势「云端前端解决方案」吔只有我们适合做这个，这里只列举了其中一个场景类似的机会还有很多。

在前端领域混了这几年总结了一套前端学习的精讲视频和學习路线，如果有对前端开发感兴趣的伙伴不管你是想转行，或是大学生还有工作中想提升自己能力的web前端党，欢迎大家的加入我的湔端开发交流群： 希望大家诚心交流！与企业需求同步。好友都在里面学习交流每天都会有大牛定时讲解前端技术!也可以关注我的微信公众号：【前端留学生】 每天更新最新技术文章干货。

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