编辑导读：低代码平台分为两种，一种是面向业务人员的，一种是面向程序员的。这两个流派面向不同的群体，产品形态也不同。本文作者认为，低代码平台并不能解决程序员的效率问题。一起来文中看看吧。

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

一、低代码的流派之争

从低代码诞生之日起，就有了渭泾分明的两种流派。一派追求颠覆式创新，希望通过类0代码的产品，直接触达业务人员，打造出一种无须IT即可将业务数字化的全新体验；另一派希望为程序员提供一站式的编程辅助，提高项目交付效率。

具体的各流派产品形态分析，可以参考我之前的文章《一文看懂低代码的现状、打法和挑战》。

二、两派低代码提供的产品价值

今天，我们再来引入一个产品分析的经典公式。

产品价值=现有产品体验优化体验-用户迁移成本-用户触达成本。

由于这两个流派的产品本就针对不同的用户群体，而“用户触达成本”这个变量很大程度取决于企业DNA和渠道优势领域，因此很难进行平行对比，我们再对这个公式进行一下简化：

那么，这个公式里最重要的两个变量就是“产品优化体验”和“用户迁移成本”，让我们以这两个变量为锚点来拆解一下这两个流派的产品，分别为用户提供了怎样的价值。

首先，来看0代码产品。主要对象是业务人员或B端产品运营，瞄准的是原本标准化的SaaS场景和一些SaaS尚未覆盖，但由于投产原因也被IT忽略的长尾需求。

在我们实际产品推广实践过程中，由于瞄准的是用户之前尚未被满足的需求，提供了一种全新的产品体验来如此高效的完成业务数字化，业务用户普遍对此比较兴奋，因此，“优化产品体验”这一项可以加上1分。

由于提供的是一种全新的产品体验，不存在客观意义上的用户迁移问题，但考虑到低代码市场还处在较为早期阶段，仍然需要投入较大用户教育成本，因此，“用户迁移成本”这一项可以减去0.5分。

现有产品体验我们统一定义为1分，那么对于0代码产品的“产品价值”得分就是：1.5分

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

接下来看针对程序员的低代码产品，我们先来拆解一下这类产品的用户使用路径，就以通过阿里宜搭搭建一个相对复杂的业务系统为例。

第一步，定义页面：拖拉拽组件，完成页面构建（同时也定义了表及表字段）

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

第二步，定义流程：通过流程表单页，拖拉拽事件组件，定义业务所需流转流程

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

第三步，定义逻辑对象，及触发动作：选择组件属性，绑定为变量

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

第四步，串联逻辑：在JS面板，以函数方法的形式完成整个应用页面间逻辑串联

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

第五步，上线：点击上线按钮，完成应用的一键上线

带着这个使用路径的实战体验，让我们再次回到那个公式。

“优化产品体验”这一项带来的提升主要体现在前端页面搭建的提效，根据我们的实际对比试验，就以标准表单页列表页搭建为例，可视化拖拉拽相比代码层级的复制粘贴，提效比较明显大约4-5倍，我们来先记5小分。

但同时，这个新的路径中也带来了一些“负优化”体验，主要体现在定义逻辑对象和逻辑串联两个环节。我们试图搭建一个案件工单处理系统的过程中，写了约500行JS代码，定义了超过50个变量，每一次的定义变量都要经历“选中组件”-“选中属性”-“定义变量”-“绑定变量”的循环，操作效率低下的同时，由于变量较多，将变量与组件唯一标识对应也是非常让人痛苦的，用我们直接上手前端开发同事的话来说就是“把节省的时间又吞回去了”，加上JS代码编写过程中的交互体验以及无法实时调试等问题，这里需要再减去4小分

最后，开发提效低代码产品“优化产品体验”这一项综合得分为1分。

“用户迁移成本”这一项是面向开发人员低代码平台的主要减分项。传统开发除了需要遵循企业研发管理CI/CD的制度规范、安全及测试相关要求，还有一个最重要的因素——集成开发IDE工具。

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

根据Stack Overflow2021全球开发者调查报告的结果，VSCode继续蝉联榜首，获评最受喜爱的集成开发IDE工具。自2011年微软邀请Erich Gamma开始孵化Monaco Editor（VSCode前身，2015年移植到桌面平台后更名VSCode），到2018年VSCode首次登榜，走过了7年的漫长时光，这期间不断进行着市场教育、产品用户相互塑造的过程。即便在VSCode霸榜多年的今天，身边很多Java开发朋友依然在坚定的选择IntelliJ和Eclipse。由此可见，对于一款毋庸置疑的生产效率工具，要想完成用户迁移的挑战是十分巨大的，更何况Web端IDE还不得不面对一些浏览器性能的客观边界，行业龙头Mendix也不得不选择自研本地IDE编辑器这种相对“笨重”的方式，来对冲这个问题。

由此可见，出于对原有生产效率工具挑战这一原因，“用户迁移成本”这一项我们来减去5分。

现有产品体验我们依然定义为1分，那么对于面向开发低代码平台的“产品价值”得分就是：-3分

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

从我们天使用户焦点小组访谈中获得的信息也同样印证了这一点。

用户表示“如果是以搭建一个重业务逻辑的复杂系统来讲，前端页面可视化拖拉拽带来的提效放在项目的全景中不值一提，而其他的体验相较于十分熟练的IDE工具，是非常令人绝望的”。

相较于0代码平台给业务人员带来的“惊喜地”完整解决方案，低代码平台的部分提效以及伴随的“负体验”和巨大迁移成本，确实无法提供较高的产品价值。

那么，除了低代码平台，究竟应该如何给程序员提效呢？

三、程序员需要什么样的提效产品

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

要想最大程度提高产品价值，我们还是要回到之前的公式，“用户迁移成本”是效率工具产品的最大挑战，无论你提供怎样优秀的新体验，都可能被迁移成本轻易的打回原形，因此面向程序员的代码级提效工具最好是维持以本地IDE为核心的产品形态，尽量少或不对用户构成迁移挑战，以便于我们更好的在“优化产品体验”条线进行发力。

这里列举了一些程序员在项目开发中会面临的关键节点，如果从一个全景视角来看，会发现有这样的几个特点：

“神聚而形散”：从抽象的角度，研发过程的确逃不出这样几个关键节点，但针对不同项目特点、团队规模以及企业研发管理要求不同，各个节点从工具选择、产出形式都没有明确的标准；
“傻活比重不小”：再整个研发过程中，除了令人兴奋的创作性工作，还存在不少重复的“傻活”。例如无趣的环境搭建、反反复复不知道写了多少遍的通用样式、常用接口。
“依赖人治”：研发过程中代码规范很依赖程序员的个人能力以及熟悉程度，人员流动造成的冲击大

基于这样的分析，我们对于要解决的问题和目标的产品形态应该有一个大致的概念了：

提高代码复用、增强自动化，减少研发过程中的“傻活”。
通过模板化加强标准规范落地，降低团队沟通及新人培训过成本。
产品形态上要抛弃“平台化”“一站式”的思想，从各个节点提效，追求累加式提升
对于单点解决问题的能力要足够深入，能否覆盖不同的项目需求

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

围绕成熟的IDE为核心的开发体系，提供一套插件全家桶，最大程度达成提效目标，应该是较好的选择：

代码工程模板、服务框架：跳出单个项目的具体情况，将同类项目模板化，更好的落地代码规范、架构规范，也免去了脚手架搭建的繁复工作。
组件库、物料库、Jar包库搭配模拟器：在落地项目、模板、代码级复用的同时，又提供了较高的灵活度，将原本需要反复编码的“傻活”简化为排列组合问题。
自动化测试、一键初始化环、AI辅助编码：通过自动化的方式，进一步降低对人员能力的依赖以及对重复工作的成本投入

四、总结

相较于0代码平台带给业务人员的“十倍改进”级惊喜的产品价值，简单的一站式低代码平台很难满足程序员对场景单点的深度需求，加之极高的迁移成本，使得这类产品的价值十分有限。

面向程序员提效的低代码产品需要摒弃“平台”的产品形态，应该以IDE为锚点，提供一套插件组合，在整个研发周期的不同节点上进行赋能提效，追求跬步千里的累加式提升。

本文由 @小博原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

给程序员的低代码平台为什么必须“死”？（低代码会取代程序员吗）

一、低代码的流派之争

二、两派低代码提供的产品价值

三、程序员需要什么样的提效产品

四、总结

相关推荐