cms前端主题框架-.net cms开发框架

前言

今年是我毕业的第10个年头。 半路出家做前端。 标题一直是前端。 可以说我很专注，有时候也会有些遗憾。 很长一段时间，别人问你是干什么的，我说前端还是全栈，别人说：哦，你是做页面的！ 心里难免有些失落。 前端是一个资源型角色，在认知上对业务的了解还不够深入。 再加上通常负责的业务范围很广，所以很难积累和沉淀。 如果你问一个毕业10年的Java老司机，他肯定是在和你聊大流量下的分布式架构，前端可能昨天吃完饭还在讨论vue和react，或者angular谁更强。 如何突破，如何为业务提供更多的价值，前端人一直在努力探索。 网上有很多启发人的文章，但是每个人面对的环境不同，负责的业务不同，所以不是都适用。 结合我这几年在阿里云做前端的经历，我也做一个总结。

1.0 版 - 工具和团队

今年是我在阿里云的第五个年头。 从来没有想过自己会在一个公司呆这么久，更没想过能在一个岗位上安顿4、5年。 刚加入阿里云控制台团队，主要负责云盾控制台、drds控制台等，在开发过程中发现大部分场景都是“表单”和“表单”。 为了避免重复开发，我封装了 simpleForm 和 console 的cli脚手架，可以一键定型新的开发控制台（直到去年才被问到怎么用这个脚手架。。。也是经久不衰）。 这时候诞生了一个可视化构建UI视图的ide，但是受限于当时团队的精力和方向，加上vscode也没有今天这么火，所以没有去尝试，这是一个遗憾。 但是做WebIDE的意义深植于心。

后来由于组织架构的调整，我从console团队中独立出来，负责当时的网站运营方向，开始了从0-1开始的艰难的团队建设过程。 那时候业务比较简单，主要是：阿里云官网和官网的Nodejs，云市场业务。 由于console团队主要使用angularjs，感觉入门成本比较高。 React 成为了我在组建新团队时的首选，也是我可以选择的时候。 那时候Vue还不成熟，唯一的选择就是React。 新技术体系需要配套的工程体系。 那时候Def还处于1.0时期。 为了稳定和降低开发成本，我们自然而然地在xef上做了插件化开发，结合​​自身业务特点，对相应的Templates进行分包，定制化开发周期。 后来由于xef1.0升级到2.0，我们的工具不稳定，变化非常大。 我们逐渐让我们的工程系统独立出来，这就导致了后来的DBL（当时叫diao）。 我跟老板汇报的时候，老板觉得这个名字不太雅致，硬要给我起个更有内涵的名字——真的很难记，我现在都想不起来了。 在这个阶段，我们做了很多技术上的尝试，团队成员都很努力，也很有激情。 我们一直在优化团队基础建设。 有了曙光基于中间件的流水线设计，可以说工程化已经达到了一个比较高的水平。 以后不管webpack升级多少，或者新的打包工具出现，对我们的影响都比较小。 面向未来的模式允许我们只在用户不知情的情况下修改内核。 新的工程方案也在积极与阿里云其他团队进行沟通交流。 此前，风驰和石染也曾达成一致，将其作为阿里云的统一构建工具进行推广，但落地效果并不理想。 同时，新方案也完全符合集团标准，与淘宝阿达团队无缝对接。 还有一个好处是：dawn不局限于react，可以使用任何框架； dawn不局限于redux，你可以用任何你喜欢的数据管理，其实我们用的是mota，mobx，graphql-apollo等等。

黎明连接：

说完工程化，其实应该说说组件化。 这是一个无法回避的问题，但对我们来说也是一个艰难的过程。 2015年，我们使用antd（开源），只是在上层做了一层业务封装； 后来融合流行起来。 与ued沟通后，考虑到团队的团结，我们使用了一段时间的fusion（开源）；最后我们选择了自己构建组件库，这是一个很无奈的举动。 具体细节不一一列举。 一个重要的原因是我们的前端业务需要“阿里云自己的设计元素”。 构建业务解决方案的业务组件。

除了折腾传统的前端领域，还尝试做了很多跨栈的事情。 在我负责的业务中，由于真正的“端”业务，我们更倾向于“全栈”。 对于前端同学来说做全栈，说实话是不够的——大部分前端同学在架构、运维部署等方面经验还是比较少的，多考虑表现层。 在全栈路径上，由于我们负责的是核心交易环节，所以没有使用大家熟悉的nodejs，而是选择了与后端相同的语言——Java。 做这个决定其实挺难的，也是有故事的。 以前有一个系统，前端同学用Nodejs写的，但是因为业务很复杂，前端一直是资源瓶颈的角色，一个人干三个人的活，所以这位同学终于想不通，离职了。 这样的系统就变成了后端想连不上，前端“没有人手”连不上的局面cms前端主题框架，非常尴尬。 从那时起，就决定在业务系统中直接使用Java。

在全栈路上，我们主要有两种策略：

大前端下写部分业务Java

利用无服务器通过代理配置转换

大前端写Java。 事实上，阿里云的很多前端已经具备了这种能力。 也有从0-1独立开发多个系统，分布式部署，支持国际化的经验。 做了一段时间后，发现效率其实还不错，并没有体感传说中的nodejs比Java效率高很多。

使用serverless通过代理配置转换，社区里有人提到Graphql一段时间，就对它产生了兴趣。 顺便了解到，可以通过proxy将后端数据转换成前端需要的格式，很是吸引人，一下子就扎进去了。 自己也做了Nodejs版给组员普及一下，做了Java版的demo给后端普及一下。 同时了解到b2b Mbox平台和我们想要的能力比较相似，就请他们分享给我们，但是因为整个业务系统都是建立在他们的平台上，存在一定的风险，所以我决定搭建自己的代理平台，也就是“云查询”。 ”平台后台。云查询主要由展峰牵头推动实施，在集团内部取得了良好的影响力，很多BU和部门都共享了。在业务方面，通过云查询，我们实现了应用的运维和部署，实现业务逻辑和接口的转换，自动扩容，尤其是营销系统，与元策银天、展丰德的合作，实现了比较大的效率提升，支撑了阿里云的去年双十一，具体的“云查询”文章介绍可以参考我的另一篇文章。

经过较长时间的发展，Cloud Query逐渐将其作为一项基础能力。 不同的“轻应用”在 Cloud Query 的 Serverless 之上成长起来，以支持不同的垂直业务场景。 例如：视觉构建领域的“页面柜”，基于权限&角色的中后台解决方案“Flex”等；

还记得5年前我说我想做WebIde，但是没有开始； 2年前，看到其他云厂商有WebIDE，我们迫于业务压力没有做； AppStudio的同学正在共建，基于AppStudio，开放我们的曙光和云查询，做云集成和一站式研发体验。

通过以上的技术基础建设，为我们打下了良好的基础。 业务布局对应于团队和组织的建设。 几年来，团队从0-1到现在xx在职同学，形成了4个梯队，三个3个业务方向&一个技术架构方向。 一路上感觉对团队的管理很深，很多时候也不是说带的人越多越好。 最近看到一本书提到“情感成熟度”这个词，很重要。 一个技术好、业务能力好的人，未必能把团队管理好。 在不同的阶段，他需要适应不同角色的要求。 最重要的是时刻保持紧迫感和持续学习。 在组建团队时，需要区分管理者和领导者。 尤其是业务团队，我们希望做leader，领导业务，而不仅仅是绩效管理。

2.0，也就是过去一年，在商业思维的指引下，我们拥有了一些业务，用横向的技术，打开横向的商业思维，取得了一些成绩，然后进入2.0。

2.0商业思维——从横向角度推动商业赋能

我们通常将组织中的人分为：一类，| 型、T型、+型。 前端恰好是一个--形的团队，负责的业务范围很广，而且前端是一个非常稀缺的职位，招人难度很大，所以盘子越大，资源瓶颈越明显。 “一字型”角色团队的典型问题是对业务的理解不深刻。 单纯从技术层面进行营销建设和中后台可视化的结果并不理想。 说到这里，你可能会觉得不能往下看。 天花板就在那里，如何突破的例子不多。 由于其中的一些见解，我写了这篇总结，我希望能给你一些输入来帮助你思考。

“一号字体”虽然在业务上我们不够深，但在专业技能上我们是标准的“|字体”。 前端经过近10年的发展，语言、框架、工具逐渐趋于稳定，各种终端的表现也越来越流畅，生态非常活跃。 我相信对于你遇到的任何困难，社区都有比较成熟的解决方案。 前端生态10年的高速发展也验证了我们有非常强的学习能力。 估计7天一个框架，3天一个数据库，也不算太难（稍微夸张了点，不过表达的意思）。 前端直接与客户对接，对客户体验的敏感度，对流程数据的敏感度，对业务逻辑流程的感知，是我们生存的根本，也是我们独有的能力。 我们不能失去这个根。

有句话说：满怀暖意不宜思淫，暂且对比一下。 前端领域的深耕，让我们成为了“稀缺资源”。 随着工具的完善，前端人也希望用技术为业务赋能。 如何赋能？ 阻碍我们前进的是“意识”。 在营销中，认知、需求、品牌、品类、价格五要素中，“认知”最为重要。 比如阿里做电商，腾讯做社交，百度做搜索。 Bat不断布局自己的主营业务领域，构建了庞大的生态，也做了很多尝试，但似乎最终还是围绕着自己的基因展开。 生态投资的成功率更高。 那我们要业务赋能，瓶颈是“你切页”也需要赋能？ 体验好，提高效率不是很好吗？ 我认为“体验和效率提升”是前端的核心能力，也是我们一生努力追求的目标。 坦率地说，我们无法立即解决资源瓶颈问题。 毕竟现在毕业生申请的是算法、AI、人工智能； 我们也做不了一轮的体验提升计划； 这是一个很长的过程。 但是，如果能从业务的角度出发，发现问题，然后用技术手段辅助解决，积累平台，满足未来不断变化的需求，或许会更实际一些。 作为一个团队，TL除了给学生“|” 专业能力有深度，也希望带领团队同学获得更多的商业经验。 谈技术不谈业务，谈中国和台湾是空中楼阁； 不谈业务就谈前端，注定只能重复造轮子，而这种低级重复正在发生，而且可能会持续很长时间。

一直以来，我都在尝试把我们“一个形”的业务广度进行抽象和整合，希望把“点”变成“线”，进而形成一个整体的“面”解决方案。 在我负责的业务中，主要有4大方向：

官方网站和营销——长尾

商务流程背景-初级

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

销售、合作伙伴

官网&营销：主要包括获客、激活、转化、留存几个节点，构建高效的“人”、“货”、“场”。 长期以来，阿里云的内容维护和营销推广都是基于集团的CMS。 传统的场馆、卡片推广方式，前端挖坑操作编辑内容。 但是，阿里云的“商品”与淘宝有很大的不同。 再加上我们没有招商选品的系统，导致这种简单的人为操作。 大促方式存在诸多弊端，如低效、不可重用、无法个性化、细粒度数据过程监控不足等。 此外，“投放”能力建设不够，无法实现针对精细化人群的营销内容精准投放。 为了解决这些问题，从去年开始，前端团队和pd共同推进了全方位营销体系的建设：

在原有产品的基础上，构建了“营销产品”的概念。 更抽象的“货”，可视化在线配置直接拉取实时价格和库存。 通过我们1.0工具搭建的曙光，打通开发流程，让整个开发环节保持一致，成本更低。 可抽象的商品搭配专门为商品打造的UI视图，形成场景能力的沉淀。

构建ACE（阿里云体验）架构体系，打通构建体系，通过技术降级打通各个“领域”，更好承载营销产品的交付。

通过全链路场景下的曝光、点击、转化、最终交易商品信息等数据的积累，生成用户画像，提供内容场景解决方案（在不同场景下向用户精准展示商品或信息），提升“人”的定位。

商业商品配置：上面提到“营销商品”时，提到了“基础商品”。 目前，阿里云的基础产品主要分为：“公有云产品”和“技术输出型”。 过去很长一段时间，我们都专注于公有云能力建设，今年年初才开始逐步融入专有云体系。 在商品化系统中，小姐姐需要配置销售规则，价格，定义商品型号； 同时，复杂规范之间的约束也极其复杂。 如何提升商业投入产出的强体验，我们还有很长的路要走。 结合今年的专有云项目，从模板的方式入手，聚合了一类产品，简化了产品型号配置的步骤，大大提高了配置效率，提升了体验。

Sales & Partners：2015年，我们刚开始组建团队（这里指的是前端团队，不是业务团队）。 2015年到18.3月，大部分部门的核心KPI是营收，首次购买者数量，主打中长期Tail客户，都实现了非常高速的市场增长。 后来团队的覆盖范围不断扩大，也负责了销售&合作伙伴体系。 围绕“营销”、“商机培育”、“商机转化”、“合同履约”构建了自己的销售CRM系统。 toC的业务通常比较好理解，毕竟我们也是c的一员。 这次toB的经历，结合第一个业务岗位的培训班，让我明白了销售体系的核心。 除了工具，我最想要的是解决方案和丰富的产品能力。

大致介绍完各个方向的业务，回到我们讨论的话题——借助横向优势，整合资源&架构，为业务赋能。 为了分析它们之间的共性，经过多次讨论，我们最终汇集了我们的业务流程图：

从这个大流程来看，各个分店最终还是要靠“销售能力”。 这销售能力

找出一个大群体中企业的共同“销售能力”。 经过一段时间的耗费资源和时间的烟囱式开发，我们抽象出了销售的核心支撑层——紫金雀。 在这个层面，我们定位为业务中心，在前端层面，也是大前端的领地。 唯一要指出的是我们用的是Java，不是nodejs，其他没有区别。 最终结构如下：

在新的架构模式下，我们减少了很多前后端的通信。 比如“分销采购市场”，用传统的方式开发需要1-2个月，而我们可以在2周内完成。 新的架构模型cms前端主题框架，在可预见的未来，可以很好地支持各种新的营销方式，以及面向销售和合作伙伴的“解决方案”。

我想说的是，如果没有我们全业务的横向视角，我们的抽象方案就不会那么通用，这就是前端团队的优势。 如果没有大前端稳定的技术生态，我们就没有机会做业务赋能。 这就是前端的未来。 利用横向优势进行整合，结合某一领域进行深化和渗透，形成纵向深度，为业务提供价值，让我们的技术解决方案“有的放矢”。 前端往往围绕一个点提出需求，获得工具，但由于没有业务属性，无法提供解决方案； 只有结合业务特点，沉淀好，工具变平台，才能释放更大的价值。

3.0 技术能力为业务增值的探索

“云计算”的核心是解决企业成本问题，以低成本获得超强的计算和存储能力，获得高并发下的弹性扩展能力。 云计算提出了很多概念：IAAS、PAAS、SAAS。 . . 和前端人物相比，物理感不是很强。 但是BAAS的出现让前端大放异彩。 想一想，我们原本需要在后台开发大量应用，逐渐积累领域能力，为前端调用提供baaS服务。 前端不再需要考虑部署运维，只关心业务代码。 目前市面上提供类似服务的公司有很多，有专门做后台数据存储的比如Leancloud，有做数据分析的，也有做消息推送的。 那么，Baas会是前端的春天吗？ 等着瞧。

谈理想，谈现状。 目前阿里云很可能是买入阿里云。 我们在IAAS层出售资源，用户的核心业务流程还是基于我们自己的研发体系。 在前端的深度领域，基于云打造“云一站式研发流程”，企业前端变成：Work In Aliyun or Dev In Aliyun。 通过对企业前端生命周期的分解，整个流程由WebIDE承载：

1. 阿里云关联代码创建

2、阿里云前端构建工具dawn作为基础构建能力，可自定义团队构建的中间件（webpack、lint、server、mock等）和构建阶段（init、dev、test、publish） ; 基于工程能力的统一规范，为各种应用框架提供初始化模板。

3、代码点击发布后，会自动编译发布到CDN。

在这个基本流程之上，我们提供无服务器相关的能力。 通过调用BaaS领域服务能力和FaaS网关触发能力，我们实际上可以提供一站式、前端主导的应用开发。

我还记得我提到过我们的无服务器应用“云查询”。 在这一层，我们逐渐将自己的能力降下来，成为Serverless的基础能力。 几乎每个公司都有营销建设体系。 以往搭建方式不够多样，主要是依靠cms能力自行开发。 随着各种“端”能力的延伸和多样化，营销建设也变得越来越复杂。 而我们基于“云查询”的“页面柜”构建系统，可以充分借助“云一站式研发流程”提供良好的SAAS服务。 这是我们的优势，也只有我们适合这个“云前端方案”。 这里只是其中一种场景，类似的机会还有很多。

总的感觉是一云多端serverless前端的春天来了。 把握核心竞争力，同时发现业务问题，跨终端推进解决方案，是最好的出路。 你问我做什么的，我……我是阿里云的CPO（首席页面男孩）。

PS：阿里云智能商务中心&阿里通信正在招聘P6-P8前端，欢迎来撩。 基地可在北京或杭州，杭州办公室位于美丽的西溪公园。 紧挨着的是UED少女&测试少女。

简历投递地址：xiaoming.dxm@alibaba-inc.com

更令人兴奋的

如果您觉得本文还不错，请点击阅读！ 点此进入开发者会场抽取Kindle等福利！ 100%中奖！