这个版块，我们梳理了包括阿里巴巴、腾讯、百度、字节跳动等知名公司的低代码建设及应用情况。其中，阿里巴巴的低代码体系建设无论是业务广度还是探索深度是比较具有代表性的，这一篇，我们讲述阿里自2008年至今十余年的低代码发展建设，看其从TMS发端到天马平台的发展演化过程，以及总结在面向营销活动等场景下低代码的建设特点。
低代码的思想由来已久，多年以前，在这个概念还未被正式提出，企业就开始了各种形式的低代码系统建设历程。以阿里巴巴为例，在多个领域都有低代码的落地场景，数据可视化、AI自助、业务流程编排、研发Pipeline、活动营销、中后台系统建站等等，涌现了一大批知名的工具及系统，用户可以使用这些工具自助完成各项工作。
阿里巴巴的低代码建设历程
在低代码以及无代码领域的探索及建设，阿里巴巴起步较早，在多个场景中有较多代表性的产品及平台产出，总体而言，经历了从工具化到平台化、从百家争鸣到生态收敛、从概念多元到范式统一等多个阶段。
我们这里以阿里巴巴在低代码最为活跃的领域，营销活动及中后台建站等低代码加以分析说明，下图是作者分析总结从2003年淘宝崛起到2022年淘宝、天猫业务再度整合，接近20年的阿里巴巴低代码发展历程。
阿里巴巴低代码发展历程
根据不同阶段的发展，在此划分为三个阶段：PC时代、无线时代以及多端时代，分别对应2003年到2013年，2013年到2018年，从2018年至今这三个大的历史阶段。科技进步永远是伴随着时代的发展而进行的，这三个阶段是阿里巴巴跌宕起伏的三个重要历史阶段，随之而来的是各种新的理念、思潮的爆发与兴替，而低代码作为其中的一部分也必然身在其中。
TMS的发端
从2003年到2013年，这是中国互联网的拓荒十年，阿里巴巴看到了toC的市场机会，借助淘宝平台开始快速发展，此后进入快速发展的车道，2008年GMV（Gross Merchandise Volume，总成交额）突破了1000亿。电子商务尤其是toC业务，天然伴生着营销活动的需求，业务与研发之间的转速差问题开始凸显，由此，淘宝面向营销的第一代低代码系统”TMS“应运而生，TMS的全称是”Taobao content Management System（也有 Template Management System 一说）“，即”淘宝内容管理系统“，从名字上可以看出，TMS延续的是此前”CMS“的思路，这也代表了企业内部初期对低代码系统的朴素认知。
CMS（Content Management System，内容管理系统），也可以理解成为网站建设系统，对于个人站长及管理员来讲不会陌生（例如知名的Wordpress、织梦CMS等），内容管理系统可以帮助他们快速建设某种类型的网站。CMS系统可以将网站配置内容与网站程序进行分开，一般成熟的CMS系统会提供大量的模版方案，让网站设计人员可以通过可视化的配置编辑即可完成对于页面、栏目的修改发布。
TMS是自主研发的淘宝内容管理系统， 集成了渲染引擎、标签体系、多CDN的内容分发以及所见即所得的模板管理功能，较大幅度提升了运营活动、资讯、专业市场等展现的制作效率，并以此为基础发展出了淘宝的个性化店铺装修系统（TMS与店铺装修系统的模块是互通的）。前端工程师开发模块，运营人员使用这些模块搭建页面并配置数据（为此演化出TCE等配套支撑系统），测试完成后发布上线。
TMS的真正意义在于生产关系的优化，业务参与到了研发生产过程中，页面开发不再全部依赖研发工程师了，研发也从中得到了一定的解放，可以将更多的精力用于打造工具上，这有益于研发团队的成长，当年TMS团队在发展鼎盛时前后端工程师加起来有二三十人，有很多与之相关的工程师因此得到了晋升。
从斑马系统到天马平台
2013年，随着智能手机的普及，阿里巴巴开始了“all-in无线”战略，随之而来的是“双端”、“跨终端”的需求，即同一张页面需要在PC以及不同手机上展现。随着流量的倾斜，Mobile first渐成共识，PC时代孵化出来的TMS不再能很好的适应移动端的需求，这给了其他搭建系统以机会，阿里巴巴内部涌现出众多的搭建系统，在营销领域，比较有代表性的是斑马系统（zebra.alibaba-inc.com）（面向通用业务），以及演化到后来有了PaaS雏形的天马平台、“方舟（天马平台上面向各类促销活动的搭建工具）”、新奥创（面向核心链路的动态化搭建工具）等等。
这里值得一提的是天马平台，天马平台是各类淘系营销类业务的低代码系统发展到一定阶段，通用化能力沉淀收敛的集中表现。
天马平台提供一系列的搭建服务，覆盖了从模块研发到托管、用户搭建到上线的各个流程。同时基于这些服务，提供了面向各类业务场景的搭建产品，例如上文中提到的面向通用业务场景的“斑马”以及面向各类营销活动的“方舟”。天马的搭建服务支撑了十几个 BU，覆盖了国内及国际化的场景，也随着海外的业务部署多个国家，覆盖亚欧美三大板块。
天马平台架构图
基础服务层：负责基础搭建数据的管理，比如模块、页面、用户、管理等模型的增删改查，这一层设计的足够通用，简单，不感知业务逻辑，也尽量少对外依赖，确保一个个功能单元足够颗粒化。
能力层：为解决上层搭建应用对于基础服务层接入难度高的问题（例如为处理用户的一个操作，可能需要调用到基础服务层的多个接口，这些操作组合还是比较容易出错的），所以在能力层对这些基础服务进行了组合，降低接入成本。另一方面，有了能力层，和大量外部系统的交互就可以在这里完成，比如和小程序后台、性能检测等平台对接。这一层的产物包括了 API 接口，搭建的脚手架，模块管理平台等等。
研发服务层：研发能力主要分为核心的构建器、提升模块研发体验的可视化研发插件、面向不同场景的初始化脚手架、以及配套的研发文档。文档也是重要功能，不管是面向开发者还是其他非技术用户。
基于天马平台，在上层逐渐孵化出多个面向不同业务场景的搭建应用，例如上文中提到的“斑马”、“方舟”等搭建应用，从而构成如下图的体系结构：
基于天马平台的类aPaaS化体系
阿里巴巴无代码系统的特点
从“斑马”以及后续面向业务侧低代码系统的建设过程中，我们能看到作为阿里前端对于这类“无代码”建设思路的思考以及此前TMS部分理念的延伸。概括来讲，这类工具更多关注以下方面：
-
无代码的搭建体验：这里的用户主要是业务运营，在实际搭建体验上，通过“楼层化”的布局、“一维扁平”的结构，TMS时代的栅格结构消失了，用户只需要关心前文中提到的搭建的（C、A、T）的C部分（配置编辑）。
除了方便用户使用，另一个重要的原因在于需求描述一致：在Mobile first背景下，来自业务侧的需求一般都是以“楼层”作为单位进行拆解的，一般一个大型活动的会场PRD（需求规格说明书）中甚至会出现不同的产品经理负责不同楼层的情况。从需求到研发、测试等整个过程，都是以这种“楼层”业务模块作为沟通确认的基本单位，简单粗暴；
-
个性化与动态化：千人千面、数据驱动的场景大量存在，模块（上文中的楼层）内部、需要哪些模块、模块的顺序等都是需要根据算法动态调整的；
-
跨终端能力：在以天马为代表的搭建平台所主导的模块规范中，通过约定的方式面向具体的端来开发，换句话说，一个模块需要支持多少终端，就开发多少特定的内容。这种情况在有了Rax（rax.js.org/）之后得到了部分改善，Rax是阿里巴巴应用比较广泛的跨端解决方案，支持开发者通过类 React DSL 编写 Web、小程序、Flutter 等不同容器的跨端应用；
-
最终用户体验：搭建产生的页面在运行时如何做到接近Native（原生）的用户体验，在业务越来越复杂的情况下如何防止体验劣化，在这些方面以天马为代表的C端搭建平台做了很多工作。
在运行前，终端容器（例如手机淘宝App、天猫App等）的各种缓存操作，包括模板、静态资源文件、数据预加载、通过预判实现容器初始化等；运行时，在数据请求逻辑中进行接口合并（接口合并负责减少请求数，加速首屏展示）、实现分页分屏（分页分屏决定了首屏需要展示哪些内容，请求哪些数据）、容灾降级（容灾打底确保最后一定可以有内容展示给用户）等功能。还有很多为了提升秒开率、减少首屏渲染时间的优化尝试，例如通过在数据请求中直出最终编译内容的SSR（服务端渲染），以及与Wormhole（基于NodeJS的模板渲染及数据网关服务）结合的方案等。
此外，包括模块的依赖声明、构建、发布、按需升降级等方面，团队也针对淘系复杂的业务场景做了各类有特色的定制处理。
以“斑马”、“方舟”为代表的无代码搭建系统，总体来讲是此前TMS系统理念在无线时代的延伸，对于低代码/无代码本身的探索突破相对不多，更多围绕在解决特定业务场景（例如动态化、个性化，与周边招商、选品投放等相融合）、性能优化、平台化沉淀等方面进行展开。
举一个例子，在物料治理方面，TMS时代的物料爆炸问题，在这些新兴的搭建系统中依然存在，在阿里巴巴的物料系统（天马模块中心或阿里巴巴模块中心）中搜索某关键词，可能会查询到数百个功能相近的模块，这些模块具有很高的相似度，但是因为缺乏更高层次的抽象以及过于追求“无代码”（从而导致没有充分挖掘业务侧的生产潜力），当一个相似的需求到达之后，要么业务“妥协”，砍掉需求直接复用此前的模块，要么研发开发一个与此前相似的模块。事实上，大家对于这类问题并非没有意识，也做了很多尝试努力，例如建立数据标准化、通过Schema解耦，模块市场化（分类标签化、热度标注、场景检验等等）、模块分层（例如方舟搭建系统的基础模块池与特定业务模块池的分离）等，但是总体收效比较有限，物料的复用率总体偏低。
物料爆炸是低代码/无代码领域的经典问题，物料爆炸指的并非物料总体数量失控，而是在同一层面（例如研发层面）相似物料出现的概率过高，从而导致同一类型物料随着时间的流逝出现了发散（没有收敛）的情况，类似上文中搜索同一关键词出现多个功能高度相似的模块。对这个问题的认知与解决大家有不同的看法，一种观点认为物料爆炸不是问题，不必追求物料复用率，因为一旦将复用率作为考核指标，那么搭建过程势必变得复杂（阿里的斑马系统的易用性就经常被运营人员所诟病）。但是，在我们看来，在追求总体生产能效提升的角度来看，物料复用率是一个重要的指标，与能效总体成正比，如何做到高复用率同时保持业务侧相对较低的搭建成本是一个挑战，对于这方面的论述，我们将在“生产力中台”一章中展开。
另一方面，前文提到过，TMS系统最大的价值在于确立了一种新的生产关系，使得业务运营与研发可以用一种新的协作方式进行生产。作为生产关系优化提升工具，这些C端搭建系统对于其他角色的联动较少，除了业务运营与技术研发，在产品经理、视觉交互设计师、测试、数据分析师等更多角色之间的协同也存在很多痛点问题需要解决，从目前的能力来看，对于这些方面关注较少。在我们看来，基于低代码/无代码的生产系统，应该成为各方角色协作的“流水线”，能够根据实际场景需要定制从而实现柔性生产，生产力平台应该成为衔接中台与业务前台中的中间部分，对于这方面的认知展开，已经在一些高层的战略规划中初见端倪，我们对未来抱以期待。
感谢阅读，下一篇我们讲述阿里巴巴在中后台、AI-Code等方向的低代码系统建设。
欢迎访问免费、通用的无代码开发平台Mybricks ，体验图形化编程的乐趣
