作者：连杰（林毅）近年来，低代码技术的发展如火如荼，也是市场关注的焦点在商业领域。作为商用低代码产品，通常是帮助企业信息化转型的利器。其核心逻辑是普及软件开发，让传统企业中更熟悉企业运营流程的业务人员可以自行开发适合自己业务的系统或平台。国内外在这个领域已经有很多有竞争力的产品，钉钉作为阿里巴巴的商业低代码产品，也是其中之一。今天的重点是另一个领域，与低代码技术在产研团队中的应用相关的话题。商用低代码产品可以赋能业务团队具备研发能力，但是对于已经具备良好研发能力的互联网厂商的产研团队来说，商用低代码产品可以解决大长尾的快速发展应用场景，但为产研团队服务的主营业务并不完全适用。对于阿里巴巴来说，集团内的BU因地制宜地打造了很多适合自己业务的低代码平台/产品。其实都是用来解决通用商业低代码产品不适用的部分。在继续阅读本文之前，先解释一下本文的目标受众。如果你是一个研发团队的负责人，想在日常的生产、科研活动中应用低代码能力来降低成本、提高效率或者解决具体的业务问题，经过研究发现适合使用诸如此类的通用低代码平台不适用。那么你可以通过阅读这篇文章从中得到一些启发。接下来，我们将从概念准备、如何实现、应用模式、常见问题及解决方案、可能的探索方向等几个方面入手：这里先做一点背景介绍。我来自阿里巴巴集团企业智能事业部。我们部门是阿里巴巴内部协同、组织治理和管理运营平台的建设者，负责IT信息化和组织数字化相关的内部工作平台建设。也正是因为这样的业务背景，所以部门的技术一直都是基于toB的基因，在低代码技术的应用和探索上也比较传统。从2016年开始，我们开始搭建前端低代码平台。该平台是目前阿里巴巴最大的通用前端低代码平台。我们也是阿里开源低代码引擎LowCodeEngine的主要维护团队。同时，通过低代码中台产品UIPaaS，我们在阿里内部孵化了数百个服务于不同业务形态的低代码平台。在服务于这些低代码平台建设的过程中，我们其实遇到了很多共同的问题和共同讨论的话题。本文实际上是对其中的一些问题进行了梳理和总结。这里的阶段划分引入了研发团队应用低代码技术成熟阶段的概念，参考了企业智能团队多年低代码应用的历史和发展阶段：试用阶段的定义：通过落地一个低代码平台/工具，在实际的产研工作中会产生一些积极的效果，包括但不限于降低成本、提升效率、解决瓶颈等。对应企业智能团队，是2016-2018年。这期间，我们着重通过构建通用的低代码平台（Lego）来解决前端研发资源的瓶颈。熟悉阶段定义：已经熟悉低代码能力，在实际产研活动中使用低代码能力解决不止一种场景问题，带来降本、提效、瓶颈等不止一种效果解决方案。对应企业智能团队，是2019-2020年。这期间，我们构建了多种不同形式的低代码产品来解决不同场景下的问题，包括模型驱动、API驱动、流程表单搭建、小程序搭建、零代码搭建、业务配置等等其他场景，从降本、系统、业务赋能、资源瓶颈解决等各方面都取得了不错的效果。集成阶段定义：低代码作为一种通用的研发能力，与团队原有的研发流程充分融合，形成统一的标准研发流程。对应企业智能团队，是2021-现在（2022年）。在此期间，我们重点关注低代码能力与传统源码研发能力的融合与共享，工具整合，流程统一。目标不仅是降本增效，更注重流程效率和研发经验的持续提升。前期准备这里重点介绍在应用低代码技术之前的一些思路和概念的准备工作。团队中低代码实施成败的关键往往不是技术本身。给团队管理者的建议Low-code是一种经过充分验证、可行的通用能力，可以带来研究效率提升、工作模式升级等好处。低代码不是灵丹妙药，合理的期望，要有耐心。低代码平台的本质是产品。对于研发团队来说，没有最好的产品形态，只有最适合的产品形态。给团队成员的建议低代码平台和开发人员并不对立和替代。低代码帮助开发人员专注于创新和创造等关键问题。积极参与变革。对于首次登陆，一般来说，大部分问题都是在团队第一次登陆低代码平台的时候出现的，所以这里对这个过程做一个深入的介绍。下面从第一阶段、中期阶段、最后阶段提出一些建议，如下图：你别想了。做完之后，发现没有必要，反而会给团队留下阴影，真正需要的时候可能会影响后续的决策。其次，明确建设意愿后，你要问自己，从产品设计的角度，这个平台为“谁”提供什么样的“形态”产品，为他们解决什么样的“问题”。“谁”是需要明确产品的用户。不同类型的用户需要完全不同的产品形态，这直接决定了产品的成败。很多平台会兼顾多种不同的用户角色，但对于首次落地场景，建议只服务好单一角色。两者兼而有之的心态不可取。试图通过一个产品形态去“取悦”不同的用户角色是不可取的。实际的。说完用户和产品形态，解决什么“问题”也很重要。也建议第一次只解决一个问题，以免过于贪心~最后，技术选型，业界有很多开源项目，包括我们的。LowCodeEngine（自卖自夸），对于大公司来说，一般都有中台平台可以直接使用，比如阿里集团的UIPaaS，优先采用成熟的技术方案可以大大降低产品实施的初期成本。在落地的过程中，首先是项目落地的节奏。在第一次迭代中，首先要做MVP（MinimumViableProduct），邀请目标用户小范围验证效果。经过快速迭代优化，逐步推广。始终关注用户的角度。低代码平台本质上是一种产品，而不是技术中间件。平台建设者最好先成为平台的用户，并与一线用户保持沟通。与C端产品不同，B端产品需要完善的产品使用文档和培训，日常的产品Q&A服务支持一般是必不可少的。习惯了C端产品的研发团队可能会追求不用学就能用的用户。对于一个好的产品，这是没有必要的……第一次落地后，一般都需要通过数据来验证效果。这里的建议是优先考虑定性分析（工艺是否更好，资源瓶颈是否得到缓解等），而不是追求精确的量化（研发效率提高了多少？），而是用户访谈或问卷调查。这时候的好手段。下一步将持续完善快读迭代，同时做好用户运营工作，包括但不限于：工作坊、培训、访谈、产品新功能通知等。应用模式为研发团队，低代码在团队中的典型应用场景可以归纳如下：解决资源瓶颈这里的资源指的是某个研发环节的人力资源。一般来说，低代码技术可以降低特定环节的技术操作门槛，可以缓解该环节的人力资源瓶颈，包括但不限于：专业前端->非专业前端需要前端->无需前端研发->无需研发BI开发->BI+业务运营自交付...交付效率提升交付效率提升也是研发团队首先会使用低代码技术的场景。在这里，我们将重点关注几乎每个研发团队都会使用的一个：模型驱动。模型驱动（又名元数据驱动），泛指通过服务端模型定义自动生成全套增删改查页面的模式，通常提供给服务端开发同学开发具有通用规则的基础管理页面.模型驱动分为两种模式。一种是从最底层的模型设计开始，服务端代码的部分也进行low-coded。一般的研发团队很难与现有业务进行整合。维护和优化也不够友好。另一种更合适的解决方案是API驱动，它通过基于OneApi/OpenAPI等协议描述的接口信息来驱动全套CRUD接口的产生。最宽的图案。业务赋能对于很多B端的SaaS/PaaS系统来说，租户通过低代码的方式对系统进行定制或者扩展是系统能力的一部分。这就是所谓的业务赋能，因为它不在本文的讨论范围之内。不多说了。常见问题在各个团队应用低代码技术的过程中，也有很多问题是大家讨论最多的。接下来，我将讨论其中的一些。编码还是渲染要回答这个问题，首先要看两者的区别和比较：编码和渲染都是低代码产品的标准应用方式，各自都有更适合的应用场景，并不是唯一的选择首先，低代码平台可以根据自己的场景需求，灵活组合两种方式。这是由于研发团队的思维惯性所致。很多人会比较关注代码输出。这里我们还将对代码输出的两种形式展开：单向转换和双向转换。理论上两种模式都可以实现，但同样的还是需要匹配到合适的用户和合适的使用场景。单向转换可以转换为更熟悉和可读的DSL缺点：代码修改后，无法转换回来适用场景：对于非前端页面场景，需要转换为特定的DSL或target语言性能优化链接需要源代码作为客户交付物双向转换需要牺牲灵活性，转换为受约束的DSL缺点：新的DSL不友好，学习成本高，与行业通用技能脱节.适用场景：多分支合并等场景用作中间代码。如何将其与团队已有的源码技术体系相结合？问题的本质是解决低代码产品如何与源代码产品集成的问题。这也是很多应用低代码技术的团队首先遇到的问题。这里涉及几个关键技术点：微前端、源码组件扩展、低代码组件。整体策略上，在生产端，低代码和源码两种生产方式可以同时存在，并兼顾联调体验；在消费端，通过微前端等技术，可以将低代码和源代码的产品进行充分的融合和渲染。这里就不多说了，大家可以参考小青之前的专题文章《关于LowCode&ProCode混合研发的思考》https://mp.weixin.qq.com/s/TY...，里面描述的很全。如何在low-code中进行多人协作和并行开发这里用一张图来说明整体策略。首先，我们要抛开传统的源码思维。在传统的源代码思维中，涉及到多人协作，多次迭代。解决方案是git版本管理。在低代码领域，更推荐产品思维。从用户的角度来看，平台本身提供低代码甚至零代码。在此前提下，版本差异合并的操作是违法的。目前我们建议的思路是：一是要弱化：通过产品设计，尽可能避免可能造成多分支协作的场景。理论上，用户操作的单位越小，多人/多次迭代同时操作的可能性越低。削弱之后，可能80%的问题都解决了，剩下的还需要加硬。在这里，您可以使用git的成熟系统将低代码转换为用户可理解的DSL以进行diff和merge。最后，低代码产品还是要回归到低代码的心态，优化多分支的产品形态。这里的重点是visualdiffandmerge的辅助决策。低代码产品的用户通过视觉排列进行生产。还需要以视觉方式查看差异；同样，对于冲突的解决，也需要一种成本更低、门槛更低的决策方法。这部分，目前UIPaaS处于早期探索阶段。探索前景虽然low-code在商业上已经有了充分的竞争和应用，但研发团队使用的领域还有很多需要不断探索。以下是我们团队未来将探索的一些方向，欢迎您的合作。探索方向的小伙伴们的参与~
