接受过初中政治课教育的我们都知道，目前软件行业的主要矛盾是「人民群众日益增长的软件产品的需求同落后的软件生产力之间的矛盾」。来自 mongodb 的一篇博客指出：

According to the International Data Corporation, there will be 750 million new applications built by 2025. That means there will be more applications built over the next few years than were built in the software industry’s first 40 years.

来源：https://www.mongodb.com/blog/post/three-factors-limiting-developers-innovation

可见，以目前两千多万正经程序员的体量，和目前落后的生产力的现状，要开发和维护七亿多新的应用程序，无异于天方夜谭。

来源：https://www.inapps.net/how-many-software-developers-are-in-the-world/

那么，有没有可能极快地增加开发人员的供给呢？很遗憾，尽管一到三个月的速成班层出不穷，可以大批量制造 CRUD 工程师，但这个增量在巨大的空缺面前依旧是杯水车薪，而且，速成班提供的工程师依旧需要 1-3 年的养成期才能配得上「正经」二字。究其原因，还是软件开发的门槛太高，开发者花在学习技术，理解代码，维护现有系统上的时间太多，导致真正用于开发新系统的精力不够，而不成熟的开发者构建的低质量系统进一步加剧了理解代码和维护代码的难度，于是再次拉低了生产力。

鉴于这种现状，2014 年 Forrester 创造性地提出低代码/无代码（LCNC）愿景，旨在能大幅降低软件开发的学习曲线，让非技术用户能够在短时间以低成本的方式构建应用。这是一种降维打击的思路：一方面，它可以大大拓宽应用程序开发者的群体，另一方面它希望能大大提升构建应用的效率。换句话说，LCNC 试图解决我们开篇抛出的矛盾：有没有可能让构建和维护应用程序的生产力激增 10-100 倍，从而让软件行业的生产力赶得上人民群众日益增长的需求？

在经历了虚无缥缈虚头巴脑的数年探索后，近两年，LCNC 开始扎实落地，在商业智能，CRM，企业内部系统，工业自动化，机器学习，电子商务，设计工具，Web/移动应用开发，以及工作流自动化等领域四处开花，很多公司实现了付费客户和收入的大幅上扬，并引起了 FAANG 等大公司的警觉。下图是 unigram_labs 对 LCNC 生态的一个总结：

你也可以到这个 google sheet：https://docs.google.com/spreadsheets/d/160sFMEpNqjJkPCr4pxRLK_yZVT7mJJRSlRG9HZNdxBQ/edit#gid=0 查阅 LCNC 公司的融资情况和最新消息。

那么，这些低代码平台是如何降低软件开发的学习曲线呢？我个人的感受是以下几个方面。

可视化工具

首先，降低开发门槛的一大利器是提供动动手拖拖拽拽就可以完成主要 UI 界面的可视化工具。对于绝大多数非程序员而言，图形化编辑界面要比 IDE 或者 CLI 友善得多。

目前 LCNC 阵营提供的可视化工具大多分为两类：以 webflow 为首的主攻设计师和无软件开发经验的产品主要通过提供 website builder 允许开发者精细化控制其页面展示：

虽然 webflow 复杂的界面编辑工具不是我的菜，但它显然抓住了包括设计师在内的很多用户的胃。这家诞生于 2013 年，没怎么融资，纯靠自力更生赚小钱钱养活自己的初代 LCNC 平台，于2019 年迎来大爆发，收入井喷式增长，并在近三年融了 300M，一骑绝尘。

可视化工具另外一个大方向是以 retool 为首的，为开发公司内部系统的程序员量身定制的极简 UI builder。它包括常用的控件，允许开发者通过简单拖拽构建展示上过得去，但可以有丰富逻辑（比如通过 SQL 从数据库中获取数据）的页面：

预置功能，第三方集成和模板

可视化工具的背后，是一系列预置的功能和模板。它们大大降低了开发者开发的门槛，使得开发者可以聚焦于实现业务逻辑，而非重新造轮子。以目前风头正劲的 airtable 为例，它提供大量预置的模板和组件，以及多达上百个与第三方 SAAS 服务的集成：

除了将功能打包成预置的模块外，还有一个很有意思的方向是将预置功能打包成库，供开发者通过极其简单的方式调用，比如 autocode 就在其 stdlib 中集成了很多第三方 SAAS 服务的 API，通过简单的 javascript 调用暴露给用户。下图展示了如何使用它来构建一个 webhook，向 slack 发送消息：

autocode 的这一思想我也实践过。今年年中的时候，我对 deno 比较着迷，试图通过 Rust 构建一系列 javascript API 提供给 deno，让用户的 javascript 代码可以通过简单的 API 访问 KV / document DB（基于 DynamoDB），文件系统（基于 s3），以及一系列 cloud API（比如 github API）。通过这种方式，用户代码基本上就是简单的胶水代码，而复杂的逻辑都被预置的库封装好了。

预置的规则和行为

在预置的功能之上，可以进一步为用户抽象出预置的功能和行为。以 clickUp 为例，当数据发生变化时，你可以从一系列预置的触发器（trigger）选择想要的触发条件，然后再选择相应的行为（action）。这种预置的规则和行为对工作流处理尤为方便，让原本需要代码处理的逻辑转化成简单的配置：

在这一点上，retool 提供了极其精细的控制 —— 比如你可以对一个表格的 row selection 事件提供相应的行为：

以上三种主要的手段帮助应用程序开发者减轻了从界面到功能，再到可复用的工作流和事件处理的工作。对于简单的应用来说，开发效率的确可以得到大幅的提升。更重要的是，开发者要阅读和维护的代码量大大减少，从而进一步降低了引用的 TCO。

AI 辅助开发

除了上述三种降低门槛的手段外，目前大热的 AI 辅助开发也许会是 LCNC 的终极解决方案。我自身是 github copilot 的深度用户 —— 近半年来我个人项目中 70% 以上的单元测试代码都是 Copilot 帮我完成的， 它大大提高了我开发的效率，使得我在不必花费太多额外时间的前提下，可以为自己开源的诸多项目提供不错的测试覆盖率。虽然 Copilot 帮我完成的代码有时还是有荒谬绝伦的错误，但大部分时候，它能够很好地领会了我的意图。而最近一个月爆红的 ChatGPT 更是把 AI 辅助开发的潜力提升到了一个新的高度。所以我觉得，从提升生产率的角度，AI 辅助开发未来在 LCNC 领域会扮演终结者的角色。虽然现在还没有 LCNC 厂商发布 AI 辅助开发的版本（可能我比较孤陋寡闻），但我相信，前面那张 LCNC 生态图中的大小公司们，都已经在它们内部迭代的产品中试图增加 AI 辅助开发：用户只需通过文字描述其对要开发的产品的想法，AI 可以生成若干个满足这一想法的产品供用户选择，最终用户仅仅需要微调就可以得到自己心仪的产品。如果这个愿景可以实现，那么这也许就是软件开发终极的生产力提升的手段！也许，我们有幸在未来的五到十年见证到人人都能开发和维护自己的应用程序的盛况，就像二十年前互联网走进千家万户，让上网冲浪，获取信息不再是象牙塔和少部分人的专利那样。

我对低代码开发平台的浅见

出于职业习惯，我对不少低代码平台都做了一些肤浅的尝试。它们在各自的细分领域都有不俗的表现，但没有特别让我眼前一亮的通用开发平台。如果我要开发一个 SAAS 服务，一个提供某个特定功能的 Web 应用（比如为开源的 excalidraw 增加 s3 存储能力），或者一个超出 CRUD 范畴的内部系统，目前的 LCNC 平台似乎都不能很好地满足我的需求。

另外，从纯程序员用户的角度，我希望 LCNC 平台支持其应用可以在生命周期内不断迭代。毕竟，开发一款软件产品只是万里长征走完了第一步，后续的随需而变，不断进化才是产品生命力的体现。这就意味着：

1. LCNC 平台需要为应用提供不同的环境（起码有 dev / staging / prod）的支持。应用可以在 dev 环境下随心所欲地开发更改，但要严控 prod 环境下的稳定性，可用性和兼容性。

2. 应用「代码」具备版本控制的能力，最好是支持 git。此外，应用的测试，CI/CD 该如何处理，需要深入思考。毕竟，一款严肃的应用离不开这些基本的开发流程的支持。

3. 应用要具备可观测性。即便是公司的内部系统，我们也需要知道其性能如何，是否有页面或者组件出现问题，也需要有足够的 audit trail 来了解访问情况。

4. 应用可以对外提供程序接口，或者抛出事件，让应用之外的世界可以与之联动。我觉得随着 LCNC 思想的深入，这是个水到渠成的需求。毕竟，一个应用不该仅仅满足于获取数据，处理数据和展示数据，还需要有能力让自己成为一个中转站或者中间人，为别的应用服务。

遗憾的是，目前还找不到满足上述需求的 LCNC 平台。很大程度上，目前的 LCNC 平台更偏重一些特定场景下的细分市场，而这些细分市场的用户画像大多是设计师，产品经理，BI 分析师，或者其它非程序员的角色。autocode 算是面向程序员的，不过它的能力太过有限；而 airplane.dev 是我见过的可能最靠近我需求的产品。它允许你撰写 yaml 和 SQL 处理大多后端需求，撰写少量 JSX 和 react 代码处理前端展示，这一切既可以在可视化工具中拖拽完成，也可以直接撰写代码，存入 git repo 中，享受其版本控制，git 工作流，github action 等一系列开发者常用的流程。

如果我来开发一款 LCNC 产品，会是什么样子的？

首先，我的用户定位会放在程序员群体。程序员一般需要开发两类应用：公司的内部系统，以及业务系统。我觉得一开始面向内部系统，解决大部分公司没有太多资源向内部系统倾斜的难题会是一个不错的切入点。这里有很好的商业机会和付费模型。事实上，retool，airplane 都是在切这块蛋糕。

而一家公司的业务系统往往是其收入核心，除非初创公司要快速验证 product/market fit，否则很难下决心使用目前还不够成熟的 LCNC 产品。当然，如果某个 LCNC 产品可以切下中小型公司的业务系统的一部分蛋糕，让中小型公司的业务 GTM 的速度大大提升，那将是一个非常了不起的里程碑。

从产品的形态来看，LCNC 产品自身是 SaaS 服务，因而需要具备 SAAS 服务的一切要素：定价模型，功能或者容量限制，用户权限，租户数据的隔离（物理或者逻辑），特定的部署需求，以及向下伸缩的能力。普通应用只需要处理自身的部署问题，而 SAAS 服务往往需要在租户切换其付费模式时进行特定的部署 —— 比如免费用户大家共享一个 DynamoDB table，切换到 pro 版本也许就要考虑为其单独提供 table。而当用户停止付费或者退出服务时，还需要将相关资源完全回收避免不必要的云服务账单。这些，都是 SaaS 产品普遍的需求。

除此之外，LCNC 产品还要具备其业务自身所需的基础功能：可视化工具，预置功能和模板，第三方集成，预置的规则和行为等等。

在这些基础功能之外，就真正考验 LCNC 产品自身的能力了。以一个通用的 LCNC 产品为例，我们可以把完整的产品逻辑都装载 lambda 函数 + DynamoDB 之内，这样可以充分利用 serverless 的可伸缩性和按需付费的计费模型，最大程度降低产品自身在 infra 上花费的时间。

也许有同学会问，为何不用 kubernetes？它也可以有足够好的伸缩性。Kubernetes 虽然很好很强大，但其背后需要一支成熟的运维团队支撑。对于初创的 LCNC 公司来说，使用 Kubernetes 可能还等不到产品找到 product/market fit，开发团队的开销就把自己整嗝屁了。

在我看来，按需使用，按需付费，几乎无限 scale up，且可以随时 scale to 0 的serverless 是应用程序的未来。除非有特殊原因或者就是做 devOps 方面的创业，否则任何初创技术团队都应将产品架构在 serverless 之上。

回到 LCNC 产品的讨论。在 lambda runtime 之前，可以考虑按需放 LB 或 API gateway，LB/API gateway 之前挂 CloudFront。目前 lambda function 支持 cloud URL，也许 CloudFront 直接访问 lambda 的 cloud URL 也是一个不错的选择。在 lambda runtime 后方，可以把 S3 封装成 FS，DynamoDB 封装成 KV store，再使用 Neon（serverless postgres）这样的解决方案，或者干脆让用户自行提供 RDBMS server（retool 就这么干），就可以为用户提供丰富的，满足绝大多数需要的 OLTP 数据访问方案：

再往后，就是常用的前后端功能的组件化。比如，每个应用可能都会使用的 oauth 登录，可以封装好，以简单的 yaml + jinja2 模板提供给用户使用：

如果要支持 email / password 登录呢？用户可以撰写下面的代码来完成整个后端的逻辑：

# step 1: lookup user---code: |    select id as user_id, email, password as hash, '{{ body.password }}' as password    from users    where email = '{{ body.email }}' limit 1;
# step 2: verify password---name: verify_passwordargs:    password: {{ password }}    hash: {{ hash }}extra_returns:    user_id: {{ user_id }}    email: {{ email }}
# step 3: generate JWT token---name: generate_tokenargs:  data:    user_id: {{ user_id }}
# step 4: trigger a user login event to event bus---name: analytics_eventargs:  type: signup  payload:    user_id: {{ user_id }}    ua: {{ headers.user_agent }}    ip: {{ headers.real_ip }}    geo: {{ headers.x_geo_data }}    ...
# step 5: render HTTP response like this307 Temporary RedirectSet-Cookie: token={{- data.item.token -}}; expires={{- data.item.expires -}}; path=/Location: /

乍一看，这样的代码虽然比自己实现要简单许多，但还是有一定的学习成本。不过这个学习成本可以通过上文所述的可视化编辑工具来消弭。

后端组件化可做的事情很多，比如各种基础的构建 app 的常见功能，大到data pipeline，implicit / explicit signals，权限管理，数据查询，数据搜索等，小到 base64 编解码，数据加解密，生成和校验 JWT 这样的单一函数。我们可以构建出一系列基础组件作为 stdlib，然后在此之上为各种各样的功能开发如上的流程模板，最大程度减轻用户开发的难度。

说完了后端，我们再来看前端的组件化。在 LCNC 生态中，绝大多数公司都花费了很多精力构建其前端组件的组合能力。毕竟，前端是门面，再优秀的后端组件，如果没有与之匹配的前端展示，也会被用户弃之如敝履。目前大家青睐的前端组件化的方案主要是 react / vue，还有少量的 svelte。这些方案用在自己的应用中问题不大，但它们是否适合 LCNC 项目呢？以 airplane.dev 为例，它采用了 react。这就势必要求 airplane 的用户群体会使用 react，或者至少愿意在 react 上投入精力。要知道，尽管 react 在工程上已经非常稳定，但它的新功能还是层出不穷，两年前的代码和现在的代码写法有很大的不同（尤其在状态处理方面）。如果未来 react 跟风要引入 signal 呢？那 airplane 跟还是不跟？用户跟还是不跟？

此外，使用 react / vue 这样的前端方案，还意味着后端需要 API 化，而前端需要维护复杂的状态。对于 LCNC 方案来说，如果最终的代码用户毫无感知还好，否则，只会增加用户维护的心智负担。

所以我个人觉得 react / vue / svelte / solidjs 等一切前端 JS 库，也许不是最适合 LCNC 的选择，对于 LCNC 项目，我们要尽量减少用户前端代码的维护成本。那么，什么样的代码维护成本比较小呢？在我看来，如果后端组件（如上所示）已经使用了模板来进行复用，前端没道理抛开模板另开一套方案。所以，也许我们可以让前端倒退 10 年，走回模板的老路？

如果小伙伴们使用过 Django 或者类似的框架，对这样的类 jinja2 的 HTML 模板代码一定不会陌生。它的可读性和可维护性不错，基本就是在 HTML 之上添加少量逻辑，由后端渲染出完整的 HTML 在前端展示。

那位问了：这么做，过去 10 年前端无刷新访问的努力难道白费了么？用户体验一下回到解放前？

非也。我们可以使用类似 HTMX 的库来达到页面局部更新的目的，就像 phoenix framework 提供的 LiveView 那样。

使用 HTML + 模板的另一个考量是即便组件化做得很好，react 工程师的门槛还是不低的，而 HTML + jinjia2 模版（其语法自 2008年以来就几乎没有变化）的门槛就要低得多。这样，无论是构建组件本身，还是使用组件，我们都可以使用更为便宜的人才达到更高的生产力，从而降低在研发方面的支出。

最后，我们来简单聊聊开发 LCNC 系统的语言选择。

我个人的首选开发语言是 Rust。这里很大一个原因是：只要你选择 serverless 方案，那么 Rust 就应该是重点考虑的语言（见这个性能测试：https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance）。我自己在 AWS lambda function 中尝试过 nodejs 和 Rust 做类似的 web 服务，包括冷启动，Rust（axum）可以轻松在 300-400ms 内完成一个请求，占用内存稳定在 ~30M 左右；而 nodejs（express）大概需要 600-800ms 完成请求，占用内存 > 100M，偶尔会超过 200M。而热启动时，Rust 可以达到 40ms 的低延迟：

冷启动：REPORT RequestId: d070a653-7f10-48b8-a9d1-26e48bf53013 Duration: 219.52 ms Billed Duration: 307 ms Memory Size: 256 MB Max Memory Used: 31 MB Init Duration: 87.08 ms

热启动：REPORT RequestId: 4d834f9a-f139-4ef6-829c-09bce5039655 Duration: 40.85 ms Billed Duration: 41 ms Memory Size: 256 MB Max Memory Used: 32 MB

（以上请求均访问 S3 获取文件，解压，抽取数据，渲染模板，返回渲染后的 HTML。热启动时感觉 lambda 到 S3 的路径上 AWS 似乎做了文件的缓存，所以速度很快）

在 serverless 的世界里，内存占用和处理速度直接决定了账单的大小。所以，Java/DotNet 这样狂吃内存，冷启动巨慢的语言直接出局，而 Rust 这样高效低内存占用的语言顿时成了香饽饽。我自己做的简单的测算，同样功能的代码，同样的预算下，Rust 代码可以支撑 4-10 倍 nodejs 的请求量。这在未来的 LCNC 产品的白热化竞争中，可以最大程度地获取免费用户且避免导致天量的账单。

Rust 的另一大好处是可以为用户代码提供高效的组件支持。通过 deno 或者 pyo3 这样的库，我们可以很方便地把 Rust 构建的组件暴露给 javascript/python 代码。于是 LCNC 的用户可以享受到 Rust 的高效，同时又可以使用简单直观的代码来构建自己的应用。