“零代码”时代已来！程序员真的要去送外卖了？

作者：流水不争先  编辑：Emma

来源| 技术领导力(ID：jishulingdaoli)

上回跟大家聊了低代码，本文接着聊一聊“零代码”。

“零代码”和“低代码”的概念是同时提出的，二者经历的背景都一致，所以就不做赘述了。

软件业经过几十年的发展，对于可视化编程语言和高级编程语言的开发逐渐成熟，同时市场对于SaaS软件的需求逐渐旺盛。

程序员都希望把软件项目的开发成本降低、开发效率提高，于是著名的咨询公司Forrester提出了“零代码”和“低代码”的概念，并带动小众的ISV开始研究“低代码”和“零代码”应用开发平台，开创出一条软件行业新赛道。

回顾一下“低代码”和“零代码”的概念：只需用很少甚至几乎不需要代码就可以快速开发出系统，并可以将其快速配置和部署的一种技术和工具。

由于“零代码”对编程工具可视化、简洁性的要求非常高，很少ISV能开发出完全“零代码”的产品，也因此“零代码”的发展速度比“低代码”稍慢一些。

“低代码”应用平台在2014年左右进入中国市场，目前处于成长期；而“零代码”应用平台则晚了两年，还在市场导入期。

在今天来看，国内相对知名的低代码软件厂商有34家，但零代码软件厂商只有17家。（数据来自中软网海比研究院《2021年中国低代码&无代码市场研究报告》）

“零代码”的技术特点

如果你试着百度搜索“零代码”就会发现，现在市面上的零代码开发平台除了色彩不一，内部的功能设计、列举的产品特色都大同小异：

• 功能灵活，随改随用。
• 实时生成应用搭建效果，所建即所见，所见即所得。
• 交互设计友好化，直观化：拖拽小组件来完成表单配置；以垂直流程图的视觉来呈现自动化工作流或智能机器人的流程动作。
• 灵活对接外部系统或插件：钉钉、企业微信对接是标配，Zapier、Processon对接是极客玩法，各种电商、SAP、供应链系统对接则是高水平动作。
• 支持跨平台使用：PC、Web、APP、H5、小程序。

以上“零代码”的技术特点自然能延伸出它的优点：

• 高效开发应用，节省时间和人力成本。
• 操作界面和开发逻辑都视觉化、交互化，对电脑小白而言更容易理解和使用。
• 开发和维护费用低，因为底层的功能都做好了，开发和维护都只是功能调用的工作，复杂度降低，所以比传统软件定制开发的项目报价便宜不少。
• 和外部系统的兼容性、互补性强，只要外部系统提供数据接口，双方就可以测试接通，在数据传输和响应上灵活互动。

作者本人也是“零代码”赛道的从业者，要说好话是十分容易。而谈到缺点，我更希望以我在工作中的所见所历，帮助大家代入场景去理解。

高度灵活化、去代码化会牺牲平台固定设计的自定义自由度。

我曾经碰过一个客户，她对某个零代码平台的界面设计不满，坚持要求数据要横向排列而非纵向排列；应该提供一个调色板，让界面所有色彩部分都能自定义搭配。对于产品要求如此“拧巴”的客户，产品经理听到了恐怕只能扶额摆手，感慨不易。

处于市场进入阶段的零代码产品，会更注重功能完善、平台稳定、用户理解和使用门槛。过度强求产品固定设计的编辑自由度，就有点舍本逐末了，倒不如直接走全定制开发来得痛快。我相信，对于比较常见、确实影响使用的功能需求，产品经理一定会认真考虑，纳入规划路线图的。

超出现有功能的需求仍然需要写代码来实现。

将用户的新历生日自动换算成农历生日，从用户的身份证号码中提取出生日期和性别，去掉手机号字段中的“+86”……这些需求看似还挺日常和普遍的，但其实现在大部分零代码应用平台都无法做到这么细致的功能点。不过，平台开发者留出了“代码块”功能，让IT极客们满足特殊需求。

CSDN上有部分程序员提出：一些简单但少用的数据处理动作，在Excel上用函数也能轻易完成，用代码块反而会变得更绕了。的确，这一点也是当前“零代码”的劣势。

外部系统集成需求无法完全满足。

目前虽然绝大部分“零代码”厂商都宣称能做到外部系统对接，但真正成功的例子却较少，因为它除了考验平台扩展能力外，还考验厂商技术团队的服务能力和甲方技术团队的配合度。

一家大型国有传统制造集团曾经找过一家零代码ISV，希望做一个ERP系统，并把他们老ERP系统的部分功能对接过来，以便集团员工逐步从老系统过渡到新系统。理想很丰满，现实却泡汤了。

失败的原因是综合的：甲方光提需求，没有配合乙方提供老ERP系统的接口数据；甲方和老ERP系统开发商的沟通也是难题，一般老开发商不太情愿配合，毕竟是要把自己的生意让出去；乙方的实施顾问“手艺”未精，也很容易把项目弄垮。

很多技术人员都会从产品功能角度说用“零代码”集成外部系统的无能；但作者反而认为，是现实项目中多方解决实施困难的决心和行动力不一致导致了这个问题。

看完以上的缺点，或许有读者会觉得：那“低代码”还是比“零代码”好一点呀，毕竟还能更灵活地实现比较复杂的需求。对此，我找到一张“低代码”和“零代码”的对比图，帮助大家做多维度对比，对号入座，选择更适合自身情况的一种。

图自：明道云博客《零代码与低代码快速开发平台的区别》

关于“零代码”，我的三个观点

上一篇科普“低代码”的文章里，我写了不少关于“低代码”行业前景的观点和材料。这次，我给大家分享三点感触，希望帮助大家对“零代码”树立新的体会。

“零代码”是中年编程小白的末班车

互联网行业爆发以来，人人都见证了程序员在社会地位上的跃进。招聘网站上铺满了程序员急招信息，高校、中小学、甚至连幼教都开设编程课，朋友圈和公众号上充斥着“30天快速上手Python”的网课。时代在告诉每一个人：不学点编程，你就落后了。

可是对80年代以前的编程小白而言，学编程谈何容易，能把房子、工作、一日三餐处理好就不错了。“零代码”对他们而言，算得上是“学编程”的替代品，能借助“零代码”做出和代码处理效果类似的成果，也能多添一个本领。（当然，替代程度大概仅为50%，也不错了）恰好，这个群体在职场上也到了管理者的位置，熟悉业务运转和行业特点，十分适合挑起大旗，搭建业务管理应用。

用什么来证明“零/低代码”有好未来：4.5亿个应用

我读过一篇很有意思的文章，里面提到：微软曾简单计算过，未来5年将有4.5亿款新应用程序将被开发出来，这比过去 40 年里开发的所有应用程序都要多。微软公司公民应用平台副总裁Charles Lamanna说：“如果这是真的，那么这4.5亿款软件必须使用低代码或零代码工具。而专业的开发人员应该专注于比费用提交表单或审批表单更困难的挑战。”

截至2019年4月，AppSheet已经在谷歌的零代码平台上创建了180 万个应用——4.5亿的进度条已启动了0.4%。

别让人人都自信地成为“零代码”应用开发者

“零代码”虽然降低了业务管理应用的开发门槛，但也很容易让对业务架构理解不当的员工盲目自信，开发出设计不当的应用，引发更大的管理问题。

曾有一家美国大型保险公司继承了1.6万个基于Quick Base（一款低代码开发平台）的应用程序，但业务员把它们运行在Quick Base的退役版本上，导致系统运作混乱。我遇到过某家公司的业务经理，他梳理的业务流程图就像缝衣服一样，线路交错，只找到流程开头和结尾，叫人哭笑不得。至于后续他把零代码应用做得如何，就不得而知了。

个人认为，真正对客户负责的“零代码”ISV，必然是对客户教育负责的。他会建立适当的流程和基础设施，作为使用引导；并配备丰富的功能学习资源，如标准的业务应用模版、学习资料、定期用户交流活动等。先给用户赋能了，再让他们开始大干一场。

尾语

有人瞌睡，就会有人送枕头。有人看到了软件开发过程复杂、漫长的痛点，于是做出低代码应用平台。有人看到了低代码应用平台在使用门槛和灵活度上的不完美，于是做出“极致”的零代码应用平台，让“Less is more”的“Less”做到“Least”。

软件行业作为一个反脆弱的系统，必然会生生不息，不断迭代。“零代码”不会是软件开发的句号，总有一个新名词会取代“Least”。我们一起拭目以待，距离下一个替代零代码的“枕头”出现，还会有多远。

参考：

1. 《零代码与低代码快速开发平台的区别》，明道云博客
2. 《无代码编程》，phodal 
3. 《无代码，低代码开发，未来5~10年发展趋势》，xyyy
4. 《2020低代码/无代码行业发展研究报告》，海比研究院