程序员们，请你们不要排斥零代码

文/明道云创始人任向晖

我们的业务进程中，不可避免地开始和开发者群体产生了一些冲突，更准确地说，是一些误会。对此，我们也有思想准备。

当然，可爱的程序员们往往都很含蓄，他们不会说——“零代码平台有什么鸟用？如果不写代码就能够开发软件，还要我们干吗？”。

他们不会说，但我们心里知道。当我们向一位潜在顾客演示明道云后，我几乎都能听到有几位程序员心里的想法。有时候，客户不同职能的人围绕是否要采纳零代码系统当面争执起来，我也有点尴尬。

有外部人士好心给我们建议将产品定位名称修改为“低代码”，而不要那么决绝地叫“零代码”。因为叫低代码，好歹不会让程序员群体过于反感，感觉自己至少还有用武之地。

事实上，明道云也包含若干低代码模块，允许部分高级用户使用脚本语言来简化配置步骤，使用API来进行对接开发，这些都离不开训练有素的程序员。

但这不是重点，我们想要达成的目标，是让现役程序员做点真正有价值的活，而把那些重复性的开发工作完全削减。称为“零代码”，的确包含一些市场宣言的意图成分。

零代码平台替代哪些软件开发工作？

概括来说，以明道云为代表的零代码平台主要用于企业中后台应用领域，尤其是围绕数据管理和工作流相关的应用类别，他们一般都用于企业内部，有时候也会延伸到外部客户和合作伙伴。这些应用都围绕数据的增删查改和灵活的工作流程管理而建立，用户通过浏览器和移动设备进行使用。

这段概括的确已经将企业软件行业中的很多场景都包括在内了。为了让读者更好理解，我再例举一些更为具体的场景：

1）基于关系数据库的业务管理应用
是指不同行业围绕着核心业务构筑的业务管理系统，例如：

• 流通业的进销存
• 制造业的生产执行、物料管理、设备管理
• 现代服务业的项目管理
• 教育行业的师资、学员、课程管理
• 设备工程业的采购、安装和服务管理
• 一般B2B行业的销售管理等等

这个大类别中大多数软件都长得几乎一模一样。在Web版本上，往往通过顶部和左侧菜单进行功能导航，主界面用表格列出数据条目，打开记录详情可以进行各种数据操作，查看关联数据。

正是因为这样的雷同度，所以零代码平台可以大显身手，将所有这些应用的实现用一个统一的组装方式来实现，从而避免从头至尾的原生软件开发过程。

2）利用移动应用采集数据的应用
制造、工程、零售等行业需要特定职能人员从一线采集数据的应用场景。

3）利用API接口写入数据并构筑管理看板的应用
从多个异构系统抽取数据，沉淀到统一的数据中台，并结合本产品的自定义仪表盘功能构筑管理驾驶舱的应用需求。这个应用场景用另外一种方式替代了BI+ETL的方案。

4）部门级解决特定业务环节需求的小应用
因为零代码系统带来的易用性和免除代码开发的特点，用户企业可以由业务部门的非开发人员直接搭建或者主导一些简单的小应用。在统一的应用管理能力下，同时也能防范影子IT问题。

5）为实现流程自动化而构建的应用
基于本产品的自动化工作流，可以打通过去需要人工协调的断续工作流程，例如：

• 订单、交付和发票的自动衔接
• 基于时间触发的检查单生成、设备维保提醒、合同到期提醒等
• 基于销售流程和营销流程之间的线索自动标签和线索培育等

6）为实现数据流转、填报和审核过程而构筑的流程应用
在复杂的数据协同中，构筑基于表单数据，审批和填写节点的人工控制工作流应用。

零代码不擅长的场景

除了这些正面范畴，也有一些负面清单。意思是零代码平台并不善于解决的场景也有很多，比如：

1）市场规模巨大，场景一致，通用程度很高的品类
比如协作应用，通讯应用。当然，因为这些市场容量巨大，也已经有大量的成熟厂商在提供产品。你完全没有必要去用零代码去搭建。如果你要参与这些市场的竞争，理应拥有一支技能完善的软件产品研发团队，才能对市场竞争做出及时的响应。

2）在特定行业中依赖非常专有化的计算或专有化的视图来提供服务的门类
例如酒店行业的动态房价管理，餐饮业的收银排桌，围绕生产制造的工业控制和特殊逻辑排程，围绕市场营销目标的广告数据管理等等。这就像要拧无数颗直径固定为3毫米的螺母，就没有必要用万能扳手。

3）面向消费者的应用
这个很好理解，2C应用是十分多元的，很难通过零代码的方式来实现。当然，那些简单的信息展示类或者购物车类的小程序应用另当别论。很多小程序生成平台，本质上也是一种零代码平台。

我相信这个清单并没有完，这个市场总是存在各种各样特殊情况的长尾，以至于每一个零星需求都不得不专门来进行架构，设计和开发。

零代码为什么比写代码还要好？

一旦你要实现的场景和我们的优势方向吻合，那么我敢说，用零代码平台搭建的应用，要比绝大多数普通软件开发团队开发出来的应用要好得多。

我这么说，可能有点不礼貌了，但我们都得客观一些，优秀和杰出的软件开发团队总是有限的，他们不会天天在开发增删查改数据的企业应用。这些活交给我们比较合适。

1）免除交互体验设计流程
零代码平台承担了基本交互设计的全部工作，围绕数据输入，查询，展示等一系列动作。应用零代码平台后，不需要再进行这些细枝末节的交互体验设计和增强。

比如：一个复杂表单的每个控件，应该用什么样式，保持什么间距，支不支持键盘切换焦点等等，这些细节问题往往耗费前端程序员大量的重复劳动。

现在，都不用了。我们的一次性范式设计统统考虑在内了。

有人说，如果不能个性化设计前端页面，那做出来的应用岂不是很雷同。的确是这样，但这种雷同是好的重复，而不是粗鄙的复制。

我们可以为一个日期输入控件耗费几天的时间来优化，这并不是所有的应用前端开发所能够承担的成本。

而且，即便你不用零代码平台，在应用前端框架时，也绝对不可能自己从头开始设计，总是会应用一些现成的成熟框架。君不见各种后台系统使用的几乎都是阿里Ant的那一套？

在企业中后台应用中，界面好看，功能好用是最重要的目标。所以，高质量的雷同正是解决这个问题的手段。

2）免除后端架构流程
前端开发容易产生重复工作，后端数据架构也是一样。为了让一个企业应用能够满足业务数据管理和工作流程的需要，开发者需要设计正确合理的数据结构。这个工作，无论是零代码，还是传统的原生开发都是需要的。

但是，除了数据模型外，原生开发项目还需要架构师设计合理的数据存储过程和函数（可重复利用的程序结构），这些工作都是依赖经验丰富的架构师的。

有了零代码平台，所有的后端架构工作被转化成可视化的配置过程，数据结构依靠表单来建立，工作流依靠触发器和节点来配置，权限系统依靠角色和颗粒度很高的权限细节来组合。

这些工作虽然不会自动完成，但它们已经不再依赖狭义的软件架构师，完成这些工作的时间成本也大大降低。

这里还要提到一个重要因素，那就是业务变更所带来的后端架构调整噩梦。

一旦业务流程产生新的需求，绝大多数情况下都不是简单地修改几行前端代码能够搞定的，后端架构都需要配合进行调整。

在过去，这是很多定制开发软件项目的危机所在，因为往往需要的时候找不到人，或者找不到健全的文档，导致后续跟进的修改中堆叠出越来越多的低质量代码。

有零代码系统，无非就是调整一下配置就能够完成。这是原生开发永远难以企及的效果。

3）简化测试流程
零代码搭建的应用也要测试，但用户只需要聚焦在数据处理的正确性上，一次对，次次对。

传统软件的测试要复杂得多，首先要有开发人员自己完成的白盒测试，还需要有需求方和测试人员共同编写黑盒测试用例清单。

光这一件事情就依赖专业人员，成本很高，而且有很麻烦的跨专业沟通。完整的测试还需要涵盖性能，兼容性等方面，相当地耗时耗力。

所以大部分定制软件开发是没有健壮的测试流程的。作为只有一个用户的定制软件，软件缺陷的消除过程非常漫长。

4）免除应用分发
开发已经掉了一层皮，但一个最终可用的企业应用，为了能够地让员工开始正常使用，还有一个“在组织内分发”的过程。

这个过程通常都比想象的复杂，尤其是那些需要根据不同角色分配不同权限的复杂系统。在软件开发完毕后，还需要引导用户注册账户，分配角色后，用户才真正能够登录系统使用。

目前，越来越多的企业已经开始使用钉钉和企业微信等平台，这意味着，开发出来的企业应用最好还能够适配这些平台，至少实现用户账户和消息通知的打通。

零代码系统一般都带有完善的企业管理后台，提供用户，部门，职能角色，汇报关系配置，还预先和钉钉和企业微信等平台接通。

这样，用零代码方式搭建的应用不仅交付迅捷，部署到用户那里也很方便。如果某个应用的角色需要对应企业的财务出纳，配置好以后，只要有人入职了财务出纳岗位，就能够自动得到这个应用的访问权和恰当的权限。

5）让需求沟通更轻松

在开发企业软件的过程中，最痛苦和昂贵的过程真的不是写代码，而是需求沟通，让开发者理解软件的应用目标和掌握必要的背景知识。在稍微复杂一些的企业软件领域，比如生产制造流程管理，物流管理，物料管理，设备管理，仓储管理和财务信息交换等环节，软件的设计源泉完全来自企业管理最佳实践。没有企业的运营知识，是绝不可能开发出可用的企业软件的。

于是乎，企业软件开发的主要成本都投入在了这些浩繁的需求沟通上。

通常是开发厂商提供一个框架解决方案，懂行的客户基本能够判断是否合适，然后客户企业需要就自己的实际运营提出组合和修改要求，开发厂商再记录在需求清单中，并用工作范畴文档（SOW）和原型图让客户确认。

即便花了很多时间做前期的需求确认工作，到了实际交付的节点，依然还会有大量的调整和确认环节。这也是为什么交付是传统软件开发服务的噩梦。成本和进度都是在这些环节上容易失控的。

零代码平台首先了提供一个可能性——不要开发人员参与，精通需求的业务人员直接自主实现，因为他们不需要掌握代码开发知识。

因为需求方直接自主实现，自然也就免去了反复的需求沟通和确认。人人都能够开发软件，这句话一半是宣言，一半已经是现实。这完全看用户自己对需求的清晰程度和学习新工具的意愿。美国人为什么习惯DIY？一方面是因为雇佣工人太贵，另一方面是因为非常发达和廉价的DIY工具支持。

就算零代码平台也是由技术团队来提供服务，业务需求方也很容易通过预先搭建的示范模块来确认是否满足需求。搭建者和使用者的沟通会非常顺畅，有时候，使用者会忍不住自己动起手来。

把正儿八经的开发力量投向何处？

零代码平台会不会替代程序员的所有工作？
我认为不能，至少在短期内是不现实的，零代码平台还有很长的产品路线图要完成。就算我们吃到大力丸，立刻把产品做得又简单好用，又强大全能（虽然天下几乎没有这样的产品），企业用户建立信任也需要时间。

至少在当下，程序员们可以开始将精力转向一些更有价值的领域。大胆地将我们擅长的领域交给零代码系统来尝试。反正我们这样的平台都提供免费试用，实现不了的，你们也不用花冤枉功夫。

但是，在没有亲手实践之前，阻止和劝导其他人不要尝试是不公道的。零代码好歹都能够搭建出可用的应用，让客户来进行实际验证，至少是局部的模块，原生软件开发就不可能这么豪迈了，客户再怎么不信任，你也不可能把软件开发好，再去和客户签合同。

真正有价值的原生软件开发应该聚焦在客户基数巨大，模式化设计能够以一当十的市场
软件产业的成功就是建立在“复制”的基础上的，如果一套软件就是一个用户，这是软件行业的耻辱。在中国市场，值得投入的软件产品领域依然很多，在有些细分市场，零代码平台也毫无优势。

比如电商ERP和延伸的新零售解决方案，智能的营销自动化工具，这些市场目前依然没有饱和，但零代码系统缺乏基础的框架模块和生态连接，做起来会比较吃力。

而且，即使有了零代码应用，也不排除客户继续选用一些套装软件产品混合使用。在这个过程中，依然有配套的集成开发工作需要完成，才能给客户提供完善的应用体验。这些集成开发涉及到围绕业务需求合理设计数据接口，建立数据调度服务，接通不同的网络环境。当然，零代码的另外一个分支——集成平台即服务（IPaaS）也在努力通过产品化来削减这些重复工作。

每位程序员真的一定要一辈子写代码吗？
如果你想在代码开发领域以外拓展视野，又想充分利用已有的IT知识，那么帮助更多的人来使用零代码平台，围绕业务需求来做好应用搭建规划，提供必要的集成开发服务，不是很好的一个选择吗？

很多程序员都希望能够多了解商业，但是仅仅是服务商业需求是不够的，参与商业需求的规划和设计才能真正转换视角，成功跨界。

从Coder成为No-Coder一点也不掉价
我总认为程序员群体最宝贵的特质是学习能力，毕竟在代码开发领域也需要不断学习和掌握新的技术栈才能持续吃好这碗饭。那么今天，当零代码成为一个选项时，明智的程序员不会盲目排斥它，而是应该好好把玩一下。如果你的确对代码开发兴趣浓厚，并有志于成为高等级的程序员，加入明道云也是一个不错的选择，因为零代码系统倒的确是用代码编写出来的（Java为核心）。