给程序员的低代码平台为什么必须死？

　　编辑导读：低代码平台分为两种，一种是面向业务人员的，一种是面向程序员的。这两个流派面向不同的群体，产品形态也不同。本文作者认为，低代码平台并不能解决程序员的效率问题。一起来文中看看吧。
　　一、低代码的流派之争
　　从低代码诞生之日起，就有了渭泾分明的两种流派。一派追求颠覆式创新，希望通过类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 协议