什么是低代码

近几年在技术领域低代码是比较热门的话题，有大量的低代码产品（包括很早就在做的和刚开始发力的）来到人们面前，像之前的serverless、区块链、元宇宙等，新鲜的概念总是更容易讲故事，有很多低代码产品也得到了资本青睐。长期以来，到目前还有不少关于低代码是否有用的争论，后面也会对这个问题给出我自己的答案。

我们先来看一个先来看一个简单示例，以对低代码概念有一个初步的认识。

下面是一个很常见的表单的示例：

作为一个开发者，如果让你实现这样一个页面，你会怎么做？

前端开发者需要在特定的框架和组件库基础上开发这个表单页面，然后本地测试，和后端同学联调，然后构建，测试，部署，最终交付给用户使用。

实际上，这种表单类的页面是非常常见的需求，每当PM角色的同学提出需求，需要先做原型，然后和研发同学沟通，然后按照流程排期，最终通过上面描述的开发过程交付到用户。

时间长了，PM可能心里会犯嘀咕，一个页面就是几个输入框，再加一个按钮，点一下按钮给我把信息存起来，需要这么费劲吗？

PM当然不会把这个问题当面说出来，如果他说出来，那么低代码的回答会和研发同学一样：“你行你上”。

这不仅仅是一句玩笑话，低代码给出的解决方案是，让开发者通过拖拽组件的方式快速搭建页面（可视化编辑），真正实现了PM可以直接上手搭建页面。这里的“开发者”就不仅限于研发同学了。

因此，所谓低代码（low-code），就是字面意义上的少代码。它是一种技术，这种技术可以支持开发者写更少的代码，甚至不写代码来提升效率。

更直观地，从使用者角度，低代码就是可以让你通过拖拽来生成页面的一种技术。

低代码产品唯一不可缺少的功能是可视化编辑

——《从实现原理看低代码》 吴多益

当然，在实际的实践中，低代码或多或少超出了这个范围，这个我们后面会更深入讨论。

上面只是一个简单的示例，实际场景中，有很多需求可以通过可视化编辑的方式来实现。比如这种营销活动页：

这个页面就是图片、文本、超链，很容易通过可视化编辑实现。

再比如表格，下面是一个低代码引擎文档上面的示例

再比如报表，用特定视图展示数据

我们可以归纳一下，这些页面（营销活动页、表单、表格、报表）都有一些共同点：

• 界面布局不复杂，而且比较稳定，没有各种嵌套和变化。
• 逻辑不复杂，没有太多循环、分支和大量数据处理。
• 交互固定，表单、超链、文本等都是默认操作，图表等组件交互也不需要太多自定义，按钮点击的行为基本就是弹窗、请求接口、执行预定义操作，如搜索，筛选等。没有酷炫动画和交互。
• 项目稳定，不会有太多迭代和扩展，没有太多维护负担。

上述特点决定了这些页面可以通过可视化编辑来开发。

低代码当然不仅适用于上面提到的营销活动页、表单、表格、报表这些场景，在一些专门的业务领域，如MIS、BPM、CRM等都有用武之地，因为这些业务领域有比较固定的一套逻辑，可以沉淀到低代码系统内部，从而对上面暴露简单的接口。

经过上面的讨论，我们可以概况一下，低代码是一种技术，它可以支持在特定的领域，以可视化的方式生成应用。

什么时候需要低代码

那么低代码开发真的比传统的开发更好吗？先说结论，在一些特定领域，答案是肯定的。如果你的业务满足上述条件，你就可以考虑尝试一些低代码的解决方案。

低代码的好处体现在效率方面，这个很好理解，对于那些对扩展性和维护性要求不高的项目，写更少的代码，效率自然更高。低代码的高效不仅体现在写更少代码这一个方面，还有其他的好处：

• low-op，“低运维”，可视化编辑的页面不需要像传统开发一样，进行测试、构建、部署。这很大程度减轻了运维成本。
• 降低了门槛，只需要很低的学习成本，就可以让需求方可以自己上手搭建页面，降低了研发成本。

而对于“低代码无法实现复杂应用（如组件间频繁通信、逻辑流程很复杂）”，这其实不能算是一个缺点，因为低代码本身不用于这些场景，不能说锤子不能用来割韭菜，锤子就不是好工具，因为锤子设计是用来敲钉子的，要割韭菜可以去买把镰刀。

当然，扩展性和灵活性比较差是低代码比较明显的缺点，因为低代码将大部分的通用需求的解决方案沉淀到系统中，向上暴露简单接口，所以无法支持个性化的应用。

从这个角度讲，低代码和serverless很像，它们都是将复杂度收敛到系统内部（例如对于低代码，虽然你只用可视化拖拽来实现一个应用而不用写React组件，但低代码内部还是要用React来渲染你的应用；你使用serverless来部署你的服务不需要考虑流量过载问题，那是因为serverless帮你实现了动态扩缩容），暴露简单接口（低代码通过拖拽实现应用，serverless你只要把你的函数部署上去即可），从而导致灵活性不高。

低代码不只是一个噱头，但也不是银弹，它有不适合的业务，也有很适合的业务，还有一些业务不太容易确定是否适合用低代码，需要开发者做权衡。

 复制代码
什么样的业务适合用低代码实现呢？我总结了几个点可以参考一下

1. 应用满足上面讲述的几个特点：界面和逻辑简单、交互固定、项目稳定。
2. 业务模式固定，使用低代码开发的场景应该是“这个业务后续的大部分需求确定可以用低代码实现”，而不是“每新来一个需求，需要思考适不适合用低代码实现”。
3. 需求量大，如果一个业务有类似运营活动页、中后台表单这种需求，但是一个月甚至半年才会有一个新需求或者迭代，那选择低代码与否区别不会很大。

还有一个相关的概念“零代码”，零代码可以看做是“低代码”的一个子集，低代码产品可以辅助研发同学提升开发效率，但有在某些情况下还是需要写一些代码来支持特定需求，而使用零代码开发应用不需要写一行代码，很适合非研发同学使用。例如很多业务场景会用Excel软件处理数据，零代码在这种场景可以作为一种替代方案。

低代码产品

虽然近几年低代码的概念比较火，但其实相关的产品和企业历史由来已久。

国外有名的产品：西门子的mendix、outsystems、salesforce、微软的Power Platform。

国内发展较晚，但近几年兴起不少企业：明道云、简道云、轻流、搭搭云、宜创、数式科技、ClickPaas、奥哲、百数等等。

还有互联网巨头也参与进来：腾讯微搭、阿里宜搭、百度爱速搭、华为AppCube（应用魔方）。

巨头入局说明一定有市场，而且市场规模不会很小，因此要讨论的问题不是低代码有没有用，而是你的业务是否适合用低代码开发。对于有些人，低代码可能很鸡肋，但对于另一些人，它是真的香。

这些低代码平台提供的产品不仅仅是拖拽生成页面这么简单，它们还提供了相应的流程管理、用户管理等配套的能力，还会和传统的CRM、BPM等结合，在特定领域提升软件开发效率，降低软件开发门槛。

前端如何学习低代码

对于前端同学如何利用低代码技术为业务赋能呢？

很简单，首先我们可以通过观察工作中的哪些工作可以通过低代码技术提升效率来找到切入点（可以参考上面提到的几个场景，活动页、表单表格报表，或者参考上面提到的几个要素判断业务中是否有对低代码技术的需求）。

然后需要掌握必要的低代码技术，其实有些低代码的厂商开源了低代码的引擎（例如百度的amis、阿里的lowcode engine）和编辑器，我们可以使用低代码引擎定制自己的组件以针对自己业务做更好的封装。还要学习如何使用开源项目，这些开源的项目都是渐进式的：我们可以根据引擎定制自己的可视化编辑器，也可以使用厂商提供的编辑器；我们可以直接使用厂商提供的低代码后端运行时，也可以自己实现服务。

关于低代码技术更深入的使用、低代码引擎的学习、低代码系统架构和原理，以及低代码的实践会在后面文章中介绍。