低代码技术在研发团队的应用模式探讨

作者：廉洁(林熠)

近几年，低代码技术发展的如火如荼，在商业领域也是目前市场关注的重点.作为商业低代码产品通常是用来助力企业信息化转型的利器，其中的核心逻辑是通过将软件开发普民化，让传统企业中更熟悉企业运作流程的业务人员可以亲自动手开发适合自己业务的系统或平台。这个领域内在市场上已经有国内外很多有竞争力的产品，钉钉宜搭作为阿里巴巴的商业低代码产品也是其中的一员。

今天重点讲的是另外一个领域，低代码技术在产研团队应用落地的相关话题。商业低代码产品可以赋能业务团队具备研发能力，但对于已经具备不错研发能力的互联网厂商的产研团队来说，商业低代码产品可以解决很大长尾应用场景的快速开发，但对于产研团队的服务的主要业务上，并不是完全适用。对于阿里巴巴来说，集团里各BU因地制宜建设了众多适合本业务的低代码平台/产品，其实也都是用于解决通用型商业低代码产品不适用部分的问题。

在接着阅读本文之前，说明下本文目标受众，如果你是一个研发团队的负责人，想在日常产研活动中应用低代码能力来降本提效或解决特定业务问题，且经过调研发现宜搭等通用型低代码平台并不适用。那通过阅读本文可以从中得到一些启发。

接下来会从 观念准备、如何落地、应用模式、常见问题及应对、可能的探索方向，这几方面来展开讲下：

这里也稍微做下背景介绍，我来自阿里巴巴集团企业智能事业部，我们部门是阿里巴巴内部协同、组织治理和管理运营平台的建设者，负责IT信息化建设和组织数字化相关内部工作平台建设。也正是因为这样的业务背景，部门技术上一直以来是toB的基因为主，在低代码技术的应用和探索上也是比较有传统。从2016年起，我们就开始建设一款前端低代码平台，这个平台目前也是阿里巴巴内部用户规模最大的通用型前端低代码平台，钉钉宜搭也是孵化自我们团队。



我们也是目前阿里开源的低代码引擎LowCodeEngine的主要维护团队，同时通过低代码中台产品UIPaaS，在阿里内部孵化了上百个服务不同业务形态的低代码平台。在服务这些低代码平台建设的过程中，其实也遇到了很多共性的问题和共同探讨的话题，本文其实也是针对这些问题进行了一些梳理和总结。

阶段划分

这里的引入一个研发团队应用低代码技术的成熟度阶段的概念，参考企业智能团队多年来在低代码应用的历程和发展阶段：

尝试阶段

定义：通过落地一个低代码平台/工具，在实际产研工作中产生某种正向的效果，包括但不限于降本、提效、解瓶颈等。

对应到企业智能团队，是2016年-2018年。这期间我们通过通用型低代码平台（乐高）的建设，重点解决了前端研发资源瓶颈的问题。

熟悉阶段

定义：对低代码能力已经比较熟悉，利用低代码能力，解决实际产研活动中超过一个场景问题，带来降本、提效、解瓶颈等不止一个效果。

对应到企业智能团队，是2019年-2020年。这期间我们建设了多种不同形态解决不同场景问题的低代码产品，包括模型驱动、API驱动、流程表单搭建、小程序搭建、零代码搭建、业务配置化等众多场景，从降本、体系、业务赋能、解资源瓶颈等多方面起到了不错的成效。

融合阶段

定义：低代码作为一种普通的研发能力，与团队原有研发流程充分融合，形成统一的标准研发流程。

对应到企业智能团队，是2021年-至今（2022年）。这期间我们重点进行低代码能力和传统的源码研发能力的融合共用、工具整合、流程统一，目标除了降本提效等常规效果之上，也能更关注流程提效和研发体验的持续提升。

事前准备

这里重点说一下团队在应用低代码技术之前的一些思想观念的准备，低代码能否在团队落地的成败关键往往并不是技术本身。

对团队管理者的建议

• 低代码是一种被充分验证可行的通用能力, 可以带来研效提升、工作模式升级等收益。
• 低代码不是银弹，合理预期，保持耐心。
• 低代码平台本质是产品，对研发团队来说没有最好的产品形态，只有最适合的。

对团队成员的建议

• 低代码平台与研发人员并非对立和取代关系。
• 低代码帮助研发人员聚焦在创新创造等关键事项上。
• 做变革的积极参与者。

首次落地

一般来说问题大多出现在的团队首次落地低代码平台的过程中，所以这里针对这个过程深入介绍下，这里分别从前、中、后三个阶段给出些建议，详见下图：

落地前

首先还是要明确建设意愿，谋定而后动，避免出现没想好就动手，作完之后发现其实并不需要，反而给团队留下阴影，可能会影响后续真正需要时候的决策。

其次，明确了建设意愿后，要问一下自己，这个平台从产品设计的视角上看，是给「谁」提供什么「形式」的产品，解决他们的什么「问题」。「谁」是需要明确产品的用户，不同类型的用户需要的产品形态是完全不同的，直接决定了产品落地的成败。很多平台会兼顾多种不同用户角色，但对于首次落地的场景，建议只服务好单一角色，既要也要的心态并不可取，试图通过一个产品形态同时“讨好”不同的用户角色是不太现实的。讲完用户和产品形态，解决什么「问题」也是很关键的，首次落地也建议只解决一个问题，避免贪多嚼不烂~

最后，技术选型，业界有很多可选的开源项目，包括我们的LowCodeEngine（自卖自夸一下），对于大公司内部，一般还会有中台可以直接使用，比如阿里集团的UIPaaS，优先选择成熟的技术方案可以大大降低前期产品落地成本。

落地中

• 首先是项目实施的节奏，第一个迭代要先做MVP（Minimum Viable Product 最小可行产品），邀请目标用户来小范围验证效果，快速迭代优化后，逐步推广。
• 时刻关注用户视角，低代码平台本质上是个产品而非技术中间件，平台建设者最好能先成为平台的用户，与一线的用户保持沟通。
• 区别于C端的产品，B端产品需要完善的产品使用文档和培训，日常的产品答疑服务支持一般来说也是必备的，做惯了C端产品的研发团队可能会追求用户不用学习就能用好产品，这个大可不必....

落地后

首次落地后一般来说都需要通过数据做效果验证，这里的建议是优先做定性分析（流程有没有更优、资源瓶颈有没有缓解等），而非追求精确的量化（研发效率提升百分之多少？），这时候用户访谈或者问卷都是很好的手段。

接下来就是不断的快读迭代持续改进了，同时也要做好对用户的运营，包括但不限于：工作坊、培训、访谈、产品新特性通知等。

应用模式

对于研发团队来说，低代码在团队中的典型应用场景总结下来有以下几类：

解资源瓶颈

这里的资源特指某个研发环节的人力资源，一般来说通过低代码技术可以降低特定环节的技术操作门槛，达到缓解该环节人力资源瓶颈的问题，包括但不限于：

• 专业前端 -> 非专业前端
• 需要前端 -> 无需前端
• 需要研发 -> 无需研发
• BI开发 -> BI + 业务运营自交付
• ...

交付提效

交付提效也是研发团队使用低代码技术最先会应用的场景，这里重点介绍一个几乎每个研发团队都会用到的：模型驱动。

模型驱动（AKA 元数据驱动），一般是指通过服务端的模型定义，自动生成全套CRUD页面的模式，通常是提供给服务端开发同学，用来开发具备一般规律的基本管理页面的。

模型驱动又分两种模式，一种是从最底层模型设计开始，把服务端代码编写的部分也低代码化，这种对于一般研发团队来说与现有存量业务结合比较困难，对于后续系统维护和优化也不够友好。另一种更适合的方案是API驱动，通过基于OneApi/OpenAPI等协议描述的接口信息，驱动生产全套CRUD的界面，该模式对服务端开发的既有模式几乎没什么改变，也是目前企业智能团队应用最广泛的模式。

业务赋能

对于B端很多SaaS/PaaS系统来说，租户通过低代码方式对系统的定制或扩展开发本身就是系统能力的一部分，这里称之为业务赋能，因为不在本文的讨论范围内，这里不多赘述。

常见问题

在各团队应用低代码技术的过程中，也有很多问题的最常被拿出来讨论的，接下来也拿出其中几个做些探讨。

出码还是渲染

要回答这个问题，首先要看一下二者的区别和优劣对比：

出码和渲染都是低代码产物的标准应用方式，各有更适合的应用场景，而且并非只能二选一，低代码平台可以根据自己的场景需求，灵活的组合使用两种方式。

这里源于研发团队的思维惯性，很多人对于出码会更更关注，这里也稍微展开说一下出码的两种形态：单向转换和双向转换。理论上两种模式都能实现，但同样的还是要匹配到合适的用户合适的使用场景上。

• 单向转换

  • 可以转成更熟悉可读的DSL
  • 劣势：代码修改后无法转回

  • 适用场景：

    • 非前端页面场景，需要转成特定DSL或目标语言
    • 性能优化链路
    • 需要源码作为客户交付物

• 双向转换

  • 要牺牲灵活性，转成有约束的DSL
  • 劣势：新DSL对用户不友好，学习成本高，与业界通用技能脱节
  • 适用场景：多分支合并等场景作为中间码使用

与团队现有的源码技术体系如何结合

这个问题本质上是需要解决低代码的产物如何与源码的产物融合的问题，也是很多应用低代码技术的团队最先遇到的问题，这里面涉及到几个关键技术点：微前端、源码组件扩展、低代码组件。

整体策略上，是在生产端，满足低代码和源码两种生产方式可以同时存在，且兼顾联调体验；在消费端，通过微前端等技术，让低码和源码的产物可以充分融合渲染。

这里不过多赘述，可以参考之前萧庆的一篇专题文章《关于LowCode&ProCode混合研发的思考》https://mp.weixin.qq.com/s/TY...，里面有非常充分的讲述。

低代码如何进行多人协作并行开发

这里借助一张图对整体策略做下阐述，首先是我们要抛开传统的源码思维，传统源码思维里，涉及到多人协作，多迭代，解法就是git版本管理。在低代码领域，更推荐产品思维，从用户视角出发，本身平台提供的便是低代码甚至是零代码，在这个前提下，版本diff合并这样的操作是违和的。

目前我们建议的思路是：

• 首先要削弱：通过产品设计，对可能产生多分支协作的场景尽可能的规避，理论上用户操作的单元越小，产生多人/多迭代同时操作的可能性就越低。
• 削弱过后，可能解决80%的问题，剩下的就需要硬刚，这里面可以还是借助git的成熟体系，通过出码等方式讲低码转换成用户可理解的DSL 进行diff和merge。

• 最后低代码产品还是要回归低码的心智，对多分支的产品形态要进行优化, 这里重点是落在可视化diff和merge的决策辅助上，低代码产品的用户，通过可视化编排的方式生产，那也需要通过可视化的方式来查看差异；同样对于冲突的解决，也需要更加低成本低门槛的决策方式。在这个部分，UIPaaS目前也处于前期探索阶段。

  探索展望

  低代码虽然在商业上已经有非常充分的竞争和应用，但在研发团队使用的领域还有很多是需要持续探索的，这里面列出我们团队后续会探索的一些方向，也欢迎有共同探索方向的小伙伴们的参与~