低代码是什么？（如何理解低代码？）

按照维基百科的说法：

低代码这个称呼是 Forrester 在 2014 年提出，指那些用可视化方式创建应用的平台，特点是代码量比传统开发少的多，甚至无代码，所以能提高开发效率。

我用上述方式和团队伙伴描述低代码，他们会一脸茫然；因为语言过于专业甚至听完之后“似懂非懂”对不对？那如何简单理解低代码这件事呢？

在我看来，它更像一种快速开发应用软件的系统。

市场或运营人员通过少量代码甚至无代码的方式在平台快速拖拽模块，构建出协同表格、采购或生产管理等一些列智能和业务类的管理系统来满足日常。

早些年，它的存在是为专业开发人员提供支持，帮助他们提取开发应用过程中繁琐“底层架构”和“基础设施”的任务；从而提高开发效率。

这两年流行起来的关键要素是“协同关系”的变化；比如：

前线业务人员想快速构建一套协同表格来传达信息，以往只能编辑好“回传”，在发送给使用人，现在只需要上云端或者某个系统中直接编辑就可以达到实时更新的效果。

它有颠覆性意义的根本在于客户一方面在软件上投入更低，另一方面显著降低了开发难度，非专业人员也能快速使用，充分调动企业各方面资源，降低对昂贵开发者的依赖。

相对相关概念

代码可分为三类：1）-码，2）低代码，3）零代码

对于-码而言，它还有两个名字，“高代码”和“传统代码”；归根结底是一回事，形容用传统方式编写网页、应用程程序或者软件。

如：你开发某款APP，企业需要招聘IOS和Android工程师、前端测试，PM等人员共同完成；这意味着开发者坐下来一行一行的敲击，并不断测试修改直到上线。

通常，这种类型的代码为主要项目服务。当为大量用户设定特定事物，并定做非常强大且独立的产品时是种不错的选择；但这需要大量的时间、金钱和精力。

那如何写出高质量的代码呢？一般有两种途径：

其一：先有好的产品经理进行通盘考虑，然后用优秀的工程师从底层架构开始搭建，进而把优秀的代码风格延续下去；犹如盖大楼，地基决定上层建筑。

其二：从糟糕的工程师开始，不断进行重构；向优秀的设计方案不断逼近，如同那句话“缝缝补补又三年”，不断修复与完善。

进一步说，高代码质量的建设基于优秀的商业模式，产品方案和业务流程，用例图，架构图不断把关键和复杂部分设计出来。

市场需要低代码的原因是企业越来越需要通过各种应用（App，小程序）来完善内部的信息流转，强化与客户的触点链接；所以，低代码本身是基于“场景”出发。

根据多方调查结果显示，在大公司内部项目失败的主要原因之一是缺乏沟通（poor communication）。

传统开发模式下，业务产品、设计开发、测试与运维人员都有自己的语言，他们各司其职，这造成长期以来很容易形成一个个“竖井”（silos），让跨部门的沟通变得困难而低效。

这也是当下为什么热门的敏捷开发和DevOps都在强调沟通，前者协同是生意，后者协同是组织和流程。

连经典的DDD（领域驱动设计）也在强调通过统一语言来减少业务和技术人员的沟通成本；因此，有低代码后可以从根本改变，各种角色在统一平台紧密协助。

1）人员聚合，2）应用聚合，3）生态聚合。

首先，将所有工作人员统一聚集到低代码平台进行作业，促进流程标准规范化；其次企业内容各应用的数据是天然互动，通过聚合的方式打通能消除数据孤岛问题。

再者当低代码平台聚合足够多的开发者，会形成无限想象力的生态体系；这无疑也是流程再造的根本。

最后说下零代码（Zero-Code / No-Code），从分类角度看零代表是完全不需要写代码的应用开发平台；这并不代表它要比低代码先进，它只是做了一个更极端的选择而已，彻底拥抱简单的图形可视化，完全消灭复杂的文本。

举个例子：

很多准新人结婚会找“婚庆机构”咨询关于场地布置问题，以前策划师在手写笔记本上通过画图为客户展示效果。

有零代码后，他只需基于平台的场景拖拽各种可视化素材，直接给出直观展示。

选择零代码背后的原因是，公司期望尽可能降低应用人员的开发门槛，让每个人都能成为开发者；这里有个概念我们要清晰，“开发不等于写代码”，它是基于业务构建协同流程。

要知道，从专业角度出发即使非常专业的开发者，技术分工精细化的趋势下（前端/后端/算法/运维）企业也很难做到独立开发和运维整套复杂应用的全栈工程师，但零代码能改变这一切。

但它也有局限性所在；比如：

一方面可视化的编辑器的表达能力远不如图灵完备的通用编辑语言，不引入代码根本无法实现灵活定制和拓展；另一方面由于目标受众是非专业人员，平台能支持的系统也是傻瓜式。

这只能做到大业务的组件简单堆叠，不支持颗粒化原子组件和灵活的布局；就好比你想更改一个icon的清晰的都很难。

总而言之，高代码构建更高维度的业务和产品，零代码是低代码的子集，目前从市场看普适性和适用性均还未达到红海效应；而低代码则满足少开发的场景使用。

由此可见此领域许多玩家早在几年前就已经存在，比如国外低代码领域一个巨头OutSystems这家公司成立在2001年；FileMaker更是诞生在1985年。

所以，广义上看它属于SaaS中的分支，但成长速度和SaaS路径对比明显要慢很多；总之低代码虽然说的很好，但市场发展并乐观；原因归属两个层面：1）技术成熟度，2）业务收益低迷。

第一个层面：RAD（快速应用开发）、BPMS（流程）、可视化开发、模型驱动这些专业工具和名词都有漫长历史，它们是低代码组成的必要条件，融合在一起显然是新瓶装旧酒，对不对？

或者你理性一点就不会这样思考，原因是1980到2015年这段时间低代码技术能力弱，表现亮眼的平台少之又少国内产品也尚未成型。

但由于投入成本没那么大，此期间也就为很多平台打下基础；直到2015-2018年AWS、Google、Microsoft和Oracle等巨头和资本入局市场才开始升温。

看过经典管理书籍《跨越鸿沟》你会明白任何的技术都会遵守所谓的“技术成熟曲线”（The Hype Cycle）。

也就是说：你不可能一出生就直接跳过发育阶段嗨翻全场被大规模采购和运用，是不是。

比如以模型驱动技术为例，虽十几年前就有“理论体系”和“配套工具”的研究，但在技术背景下，由于能力不完备过于理想化等原因一直没能在工业界走向主流。

从现在视角看，支撑低代码的“老技术”已经通过几十年的酝酿打磨变得稳固，另一些完美互补的新技术（e.g.云原生、响应式web）均慢慢走向成熟，加上企业线上数字化的渴求，那低代码也就顺水推舟。

目前市面的中小公司有两种状态：

1）疯狂踩坑，2）一张白纸。

前者他们吃过各种定做APP、小程序/H5的亏，投入巨大收入效果甚微；后者初创公司想做技术，但又没有较多成本预算花在人工运维上。

除此外，对大公司来说，想开发款软件内部流程环节复杂，这无疑没办法快速试错。

据此在内因、外因的共同作用下，低代码成为被风口选中的行业；加上资本的涌入无疑就火爆起来。

被高估还是被低估

查理·芒格有个经典的思维模型叫做“10-10-10”原则。

讲的是在决策时思考三个问题，即：这个决策在10分钟后会产生什么影响？10个月后、10年后呢？在我看来，低代码的价值短期被高估，长期被低估。

为什么？不妨我们看一组详细数据。

全球权威的技术研究和分析公司Gartner发布的《2021年中国ICT技术成熟度曲线报告》（以下简称“报告”），首次将低代码应用开发平台（LACP）作为新兴技术热点被纳入。

Gartner的报告研究常规覆盖20多项新型技术和实践，也就是说在过去几十年中低代码并未能够真正拿出台面；而今天居然以新赛道的方式出现，这无疑反应该技术在全球的崛起与未来增长的潜力。

《2021年中国ICT技术成熟度曲线报告》

把视野放到国内，从行业规模看，2021年海比研究院数据表明中国低代码厂商约有120家，IT桔子盘点投融资情况达15起。

预计到明年能达到200家的体量；以头部为代表的有简道云、明道云、伙伴云、飞书、金蝶等。

从市场份额角度出发，今年低代码规模达到28.5亿；未来五年复合增长率为49.5%，明年可达42.6亿；2025年预计达到142.2亿；从使用者需求，低代码平台被分为四种类型：

1）场景应用型，2）产品研发型3）平台生态型，4）技术赋能型

场景应用是为具体细分领域业务而打造，开发侧重于企业自用；生态属于头部布局中软件的某一分支；技术支持则代表更底层的算法、区块链等方面的协同；收入模式占比最高的是前三者。

我们能得出什么启发呢？

低代码在全球视角下经过几十年沉浮，终于以稳定增长模式进入大众视野并且被市场所认可；智远根本两则“报告”总结，认为呈现三种趋势：

首先，2020年将会有40%-60%的企业使用低代码开发应用，其次企业从独立研发APP开始向数字化平台转变，并且将大企业数字化应用作为基础设施。

再者大量平台的出现，会加速企业核心业务的系统开发；进一步说，低代码能够支撑起高复杂度，高技术、超大规模的应用开发。

并且将整个链路覆盖到以客户管理、运营流程、生产、配送为代表的核心业务部分；这种结构性的变化并且还会持续细分。

由此可见，头部巨头正在以生态为中心引入“低代码”厂商；整个大市场热度呈现先抑后扬；国内这么多家低代码公司突出赛道的关键点在于：1）产品使用门槛要低，2）行业积累要深耕。

也就是说：低代码公司和巨头平台结合，找到某个点切入细分和小众市场，聚焦一个领域做深做透；深度运营和培训客户并建立壁垒，才能实现长期主义共赢。

如何选择低代码公司

资本有好有坏，难免也让“创业项目”变形。

因为创始人的对赌协议想快速回笼资金而忽略产品体验的公司不计其数，有些则默不作声的打磨技术，在市场没有任何声音也很多。

在混战的低代码江湖中，中小企业要不要用低代码或怎么选适合自己公司的产品呢？这里有三个思考：

1）产品公司实力，创始背景首先如前所述，目前属于行业爆发期，夸张点看似乎没有一家低代码公司不说自己是“专业软件”公司的；那么，借此风口来抢杯羹的大有人在。

假设因为预算而选择家新创立或“团队基因”一般的公司，可能以后在数据和产品使用方面的坑会踩不完。

我并非说“新创立”的公司不行，而是我们要看准合伙人资历，对行业思考以产品定位等各要素；那大公司或上市公司背景就一定好吗？未必。

有些企业虽有历史但通过兼并收购方式买下某个产品是为补齐每年财报短板，营收业务开展方面显得好看。

所以他们通过此手段赶紧发布低代码平台好抓紧抢占客户，技术方面肯定不行的，无疑你就成了小白鼠。

其次是产品的发布时间，一般来看2015年左右的公司无疑在此行业算做足详细调研。

因为2015年左右低代码经历过一次低谷期，也许当时他们前身并非是该行业，但能确定押注此赛道并活到现在说明创始团队的眼光具有前瞻性。

再者从公司内部出发，落地某个项目时难免会遇到今天开发的功能没用上，过段时间发现此功能又有用，所以版本的管理也很重要。

有些企业虽内部运用该软件，但能否支持协同开发还是有必要的；除非是内部特别小验证的项目，这方面我相信负责过项目的人应该非常感同身受。

2）业务是否真需要低代码不论从高管视角还是业务出发，很多公司整体认知对“低代码”并没有概念；即“他们不知道这个东西是什么”或“我用它解决什么问题”；当对产品了解后才知道“原来可以这么干”。

一般来说，企业不会用低代码从零开发整套核心业务，比如ERP/CRM、甚至BOS智慧运营系统等；如果需要直接买套成熟解决方案即可。

所以就目前而言，低代码更适合核心数字化系统之上，构建创新类的应用和敏捷运营类的运用；用最土的话表达是“解决企业到用户之间最后一公里的事情”。

那么比较适合用低代码的场景有哪些呢？我总结为5大方面：1）门户端，2）数据操作和展示端，3）业务流程端，4）移动端，5）基于所有表格的运用

门户包含APP，小程序，PC网站；数据方面包括通过链接企业内部的数据库把生产经营打通，进行展示和简单互动沉淀；业务流程包含跨部门协助、OA审批、人力财务等。

举个例子：

现在要办场1000人规模的行业大会，我们可以通过低代码构建人员分工，物料明细和协同进度完成整体策划执行，它可以像OKR一样让所有人看到每个人都在做什么，从而来相互配合。

在移动端具体表现有核心经营系统管理系统，如考勤打卡；表格运用场景相对比较多，譬如基于数据库的表单收集整理、统计处理等。

这是我从市场运营视角出发的角度整理，不难看出，以上五种类型算是覆盖企业80%的数字化系统，除此外还覆盖更多行业基本面，如教育、文旅、零售、金融等，不一而论。

3）是否是三位一体通过分析国外的低代码领导型公司，可以得出他们在业务上的创新方式是“组合式”。

比如Outsystems之前是做BPM（业务流程管理），SAP、Microsoft之前是做aPaas和MADP（移动开发平台）的重组，Kony也是做相似。

由此可见，把BPM，可视化和aPaas融合加上组件云原生经历市场打磨才形成“低代码”平台；所以说这三种能力是国内公司也不可缺失的，总结为：1）MADP，2）可视化，3）aPaas

第一：大部分低代码平台基于模型驱动横跨平台开发能力，MAP能够更好地应对中小公司数字化业务和创新的需求，持续演进的组件可根据需求快速建立新的建模器和产品服务。

第二：“可视化拖拽编辑器”是基本配置，若这方面不能解决就不能称为低代码平台，难道让一个收银员或运营写英文表格吗？显然不现实。

第三：aPaas是PaaS（平台即服务）的子形式，它能支持应用程序在云端开发和部署，能提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等；没有此能力企业无法私有化部署。

基于三者之上所谓的一体是什么呢？即：配套的生态。

换句话说，通过此低代码平台能不能完成和其他云与企业内部的数字化链接打通的能力很重要。

总而言之，不同平台都有自己的定位，假设没有这三者基础我想企业没必要选择，从价值链角度出发，它也是基于企业数据产生“信息环”当中必要的一环。

总结一下：

我们会看到各种新技术（算法）、模型和产品的问世，复杂的让人难以理解对不对？

但好像它们都逃脱不了旧公司和新产品的组合；或新公司装旧产品使用“新宣言”。

任何B2B企业以客户需求为核心出发进行场景细化，万变不离其宗好；你看，时间从不语，却回答了所有问题。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。