到底什么是低码？
什么是低码？
什么是“低码”？如果是第一次听说，大概和我从老板那听到一句话后的内心戏是一样的:什么？“低码”？“代码”就是代码的意思，我知道，但是“低”这个词是什么意思？不会是老板发现我匆忙写的代码又丑又“低”吧...我想多了，那老板怎么自己审核代码呢？那是指“低级编程”中的“低”吗？老板终于觉得让我和其他编程奇才整天堆Java业务代码太浪费了，派我去写一个高性能的C语言网络库...显然不是，老板怎么会有这种技术感？这到底是什么意思？作为一个商比情商高的程序员，凡是能问谷歌的，绝对不会问老板。于是一次操作之后，我不假思索的打开了第一个搜索结果:低代码开发平台。
维基百科定义
从维基的这个定义中，我们可以提取几个关键信息:
●代码开发平台(LCDP)也是一种软件，它为开发者创建应用软件提供了一个开发环境。看到“开发环境”这几个字亲切吗？对于程序员来说，低代码开发平台的本质和IDEA、VS等代码IDE(集成开发环境)几乎是一样的，都是为开发者服务的生产力工具。
与传统的代码IDE不同，低代码开发平台提供了一个更高维度的、易于使用的可视化IDE。大多数情况下，开发人员不需要使用传统的手写代码进行编程，而是可以通过图形化拖拽、参数配置等更高效的方式完成开发工作。
Forrester定义
根据Wiki的描述，可以发现“低代码”一词早在2014年就由Forrester提出，其对低代码开发平台的祖先定义如下:
请点击输入图片说明。
与Wiki版本相比，这个定义更倾向于阐明低代码带来的核心价值:
低代码开发平台可以实现业务应用的快速交付。换句话说，不仅仅是“能够”像传统开发平台一样开发应用，低代码开发平台的重点是更快地开发应用。更重要的是，这个速度是颠覆性的:根据Forrester在2016年的研究，大多数公司反馈低代码平台帮助他们提高开发效率5-10倍。而且，我们有理由相信，随着低码技术、产品和产业的不断成熟，这种推动因素还能继续上升。
低代码开发平台可以降低商业应用的开发成本。一方面，低代码开发在整个软件生命周期过程中的投入更低(代码编写更少，环境设置和部署成本更简单)；另一方面，低代码开发大大降低了开发者的使用门槛。非专业开发人员经过简单的IT基础培训即可快速上岗，不仅可以充分调动和利用企业各方面的现有人力资源，还可以大大降低对昂贵的专业开发人员资源的依赖。
低代码核心能力
基于以上定义和分析，不难总结出低代码开发平台的以下三个核心能力:
请点击输入图片说明。
全栈可视化编程:可视化包含两层含义，一是编辑时支持的点击、拖动、配置等操作，二是编辑后所见即所得的预览效果。传统的代码IDE也支持一些可视化能力(如早年Visual Studio的MFC/WPF)，但low code强调全栈、端到端的可视化编程，涵盖了一个完整应用开发所涉及的所有技术层面(接口/数据/逻辑)。
生命周期管理:作为一站式应用开发平台，low code支持应用的完整生命周期管理，即从设计阶段(部分平台还支持更高级的项目和需求管理)，经过开发、构建、测试、部署，到上线后的各种运营(如监控报警、应用上线下线)和运营(如数据报表、用户反馈)。
代码扩展性低:用低代码开发时，大多数情况下仍然离不开代码，所以平台必须能够在必要时用少量代码支持应用级别的灵活扩展，比如添加自定义组件、修改主题CSS样式、自定义逻辑流程等。一些可能的需求场景包括:UI样式定制、遗留代码重用、特殊加密算法、非标准系统集成。
不仅仅是写更少的代码。
让我们回到最初小白的问题:低码中的“低”是什么意思？答案是显而易见的:不是说抽象程度很低(恰恰相反，低代码开发的抽象程度高于传统编程语言)，也不是说低代码生成的代码很低(恰恰相反，低代码生成的代码一般都经过精心维护和反复测试，整体质量优于大多数手写代码)，而是简单地“少写代码”——少数情况下只使用手写代码，大部分时间可以使用可视化等非编码。
往深里看，低代码不仅仅是少写代码:代码写得越少，bug越少(所谓“少做少错”)，所以开发过程中少了两个支柱任务:“赶需求”和“修复bug”；要测试的代码更少，所以可以少写测试用例；平台除了开发阶段，还涵盖了后续的应用构建、部署和管理，因此运维操作较少(低代码→低运营)。
但是，少并不是最终目的:如果单纯想达到少的效果，削减需求，减少人力，降低质量要求都是一样的。低代码背后的哲学是少即是多，或者更准确地说，用更少的资源做更多的事情——更多的能力、更快的上线、更好的质量和更低的成本，这深刻地践行了阿里“既要又要”的价值观的精髓。
请点击输入图片说明。
平台的责任和挑战
以上是低代码给开发者提供的能力和吸引力，那么作为服务提供商和应用载体，低代码开发平台本身应该承担哪些责任，会遇到多大的挑战？有必要像阿里云倡导的那样“把复杂的留给自己，把简单的留给别人”吗？虽然这句话听起来很深刻很清晰，但不知道大家有没有想过，为什么一定要抓住复杂不放，平白无故的给自己找东西。难道我们就不能把复杂的干掉，把一些简单的东西留给阿里云自己的员工吗？是工作太容易体现KPI的价值，还是家里的饭菜没有公司的宵夜香？
苦思良久，我从热力学第一定律中找到了答案:开发一个应用的总复杂度是恒定的，只能转移不能消失。如果开发者想做的更少，享受简单的快乐，那么平台方就得做的更多，默默承担尽可能多的复杂。就像一个浑身是筋的杂技演员，稳稳地托起正在高空旋转跳跃的女伴；上面的人显得越轻盈、越不费力，下面的人就越稳重、越疲惫。当然，并不是说上面这些女星都很放松，没有压力，只是她们各自的分工不同，复杂程度不同。
根据《人月神话》作者弗雷德·布鲁克斯的划分，软件开发的复杂性可以分为本质复杂性和偶然复杂性。前者是解决问题所固有的最小复杂度，与你使用什么样的工具、经验是否丰富、架构好不好无关，后者是实际开发过程中引入的复杂度。一般来说，本质复杂性与业务要解决的具体问题域有很强的相关性，所以我称之为“业务复杂性”，在这里更好理解；这部分复杂性是任何开发方法或工具都无法解决的，包括低代码。偶然复杂性一般与开发阶段的技术细节有很强的相关性，所以我相应地称之为“技术复杂性”；而这部分复杂性正是low code所擅长和适合解决的。
作为低代码开发平台，尽可能屏蔽底层技术细节，降低不必要的技术复杂度，支持其更好地应对业务复杂度(满足灵活通用的业务场景需求)，是开发者的核心职责。
请点击输入图片说明。
在履行上述职责的同时，低代码开发平台作为面向开发者的产品，还需要致力于为开发者提供简单直观的极致开发体验。除了这背后巨大的工作量，我们还必须在“功能强大”和“易于使用”这两个矛盾之间，努力找到我们的产品定位和目标客户需求之间的平衡——这可能是设计一个通用低代码开发平台的最大挑战。
三、低码相关概念的比较
纯代码(专业代码/定制代码)
“纯代码”可能是我发明的一个词。更常见的是，它是亲代码或定制代码。但意思是一样的，就是指传统的以代码为中心的开发模式。之所以选择使用“纯代码”，是因为如果使用“专业代码”，会显得low代码不专业，而使用“自定义代码”则容易让人误解为low代码无法支持定制的自定义代码。
当然我觉得更准确的名字是“高码”(正好对应低码，但是名字太难听了，所以不喜欢...)，因为即使使用传统的代码IDE，有些开发工作也支持(甚至更适合)非代码补全，比如iOS开发中使用的SwiftUI界面设计器，数据库应用的服务器开发中使用的PowerDesigner建模工具。但这部分可视化工作在传统开发模式下只是起到辅助作用，最后通常生成开发者可以直接修改的代码；开发人员仍然关注代码来执行他们的主要工作。
低代码和纯代码的关系其实很像视频和文章的关系:
低码就像现代的“视频”。大部分内容由图片组成，直观易懂，表现力强，因此更容易被大众接受。但同时，视频不够刚性，不能有图片，可以加入少量文字(如字幕、注解)来弥补图片表达不准确的问题。BTW，关于“图”与“文”的辩证关系，可以进一步参考《建筑制图:工具与方法论》[1]一文中的相关描述。
纯代码更像是传统的“文章”。虽然长期以来一直是信息传播的唯一媒介，但随着视频技术的诞生和相应软硬件基础设施的普及，逐渐被抢了风头。如今，视频已经成为大多数人获取信息的主要渠道(从电视和电影到哔哩哔哩和Tik Tok)，但越来越少的人经常阅读书籍和文章。但不可否认的是，文章还是有它的意义和受众的(不然我也不会费心打那么多字)。即使“市场份额”受到了挤压，也总会有它立足的空间。
请点击输入图片说明。
按照上面的类比，low code未来会走类似于视频的发展轨迹，超越纯代码成为主流发展模式。Gartner的预测也表达了同样的观点:到2024年，所有应用程序开发活动的65%将由低代码完成，75%的大型企业将使用至少四种低代码开发工具进行应用程序开发。
但同样，就像视频永远无法取代文章一样，低代码永远无法完全取代纯代码开发。未来，低码和纯码模式将以互补的形式长期存在，各自在适合的业务场景中大放异彩。在后面的“低代码业务场景”一章，我们会详细列出现阶段哪些场景更适合用低代码模式开发。
零代码/无代码
从分类的完备性来看，如果有“纯代码”，自然也应该有完全相反的“零代码”(也叫“无代码”)。零代码是一个完全不需要写代码的应用开发平台，但并不意味着零代码比低代码更高级、更高级。它只是做了一个更极端的选择:完全拥抱简单的图形可视化，完全消除复杂的文本代码。选择背后的原因是希望零代码开发平台尽可能降低应用开发的门槛，让每个人都能成为开发者(注:开发≠写代码)，包括业务分析师、用户运营甚至是根本不懂代码的产品经理(装不懂就是不懂)。
即使是专业开发者，在技术分工越来越细的趋势下(前端/后端/算法/SRE/数据分析...)，很难招到一个能独立开发和维护一整套复杂应用的全栈工程师。但零代码可以改变这一切:无论是分不清Java和JavaScript的技术小白，还是精通深度学习却没有时间学习Web开发的算法大牛，都可以通过零代码实现自己的技术梦或者全栈梦。“改变世界的想法就在那里，只需要一个程序员”，这个笑话可能真的会成真；哦，不，你甚至不需要一个程序员。有想法的人可以自己做。
请点击输入图片说明。
当然，所有的选择都是有代价的，零码也不例外。完全放弃代码的代价是有限的平台能力和灵活性:
一方面，可视化编辑器的表达能力远不及图灵完整的通用编程语言，不引入代码无法实现灵活定制和扩展(当然理论上也可以做成类似Scrach/Blockly的图形化编程语言，但那只是手写代码的另一种形式)。
另一方面，由于目标受众是非专业开发人员，平台所能支持的操作会趋于“愚蠢”(如页面只支持大型业务组件的简单堆叠，而不支持细粒度的原子组件和灵活的CSS布局定义)，同时，只会展现相对“人性化”的模型和概念(如使用“表格”来表示数据，而不是“数据库”)。
请点击输入图片说明。
虽然狭义的零码和低码有明显的区别，但广义的零码可以看作是低码的子集。Gartner在其相关研究报告中，只是将“无代码”归为更广泛的低代码应用平台“LCAP”。目前市面上很多常见的低代码开发平台也有一定程度的零代码能力；比如低代码领域的领军企业Mendix，不仅提供了简单易用的零代码Web IDE——Mendix Studio，还包含了更强大的低代码桌面IDE——Mendix Studio Pro。
高生产力应用程序平台即服务
如上所述，“低代码”这个词是Forrester给出的。作为国际知名的研究机构(又名造词专家)，Gartner显然不会在这场可能决定低代码领域江湖地位的新概念造词大赛中轻易放弃，所以也在2017发明了“HPA PAAs”(高生产力应用平台即服务)这个缩写词。
根据Gartner的定义，HpaPaaS是一个支持声明式、模型驱动的设计和一键部署的平台，提供在云上快速应用开发(RAD)、部署和运行的特性。这显然和低码的定义一模一样。不过，事实证明，名字起得太专业也不一定是好事。最终“HpaPaas”败给了出身更早的“低码”，更接地气，更流畅。从2019开始，Gartner也开始在相关研究报告中全面采用“低码”(如LCAP)一词，并亲自为“HpaPaaS”标注@ dep。
请点击输入图片说明。
来源:SaaS/IaaS/PAAs/APAAS/HPAPAAs有什么区别？
值得补充的是，“HpaPaaS”这个词并不是天生的，而是继承了Gartner早前提出的“aPaaS”。它们之间的关系是:HPA as只是aPaaS的一个子类；除了低代码实现的高生产力应用开发平台HPA as，aPaaS还包括面向纯代码的传统应用开发平台(高控制aPaaS，即控制程度更高的纯代码开发模式)。
不值得八卦的是，“aPaaS”一词并非凭空捏造，而是与云计算的兴起有着很深的联系。相信云道的各位都猜到了，aPaaS和IaaS/PaaS/SaaS是云计算的古老概念:aPaaS介于PaaS和SaaS之间，比PaaS提供的服务更具应用性，但并不像SaaS那样提供现成的软件服务(更详细的解释请参考有图的出处文章)。
第四，为什么需要低代码？
低码是什么可能没那么重要。毕竟在这个信息爆炸的世界里，总是缺少新奇短暂的东西。所谓的新技术，大多只是昙花一现:出现了，被看到了；大多数人“哦”了一声，看了却表示不感兴趣；少部分人惊叹于它的奇思妙想，兴奋地称赞它，转而想用什么还是用什么。真正决定一项新技术能否转化为新生产力的，从来都不是技术本身有多优秀多华丽，而是是否真的需要，也就是为什么需要低代码？如果把上面的问题用不同的科目来填充(冷知识:这叫“延迟科目初始化”)，可以更全面的看这个问题:
为什么“市场”需要低码？
在这个所有大爷大妈都充斥着“互联网+”和“数字化转型”的时代，企业越来越需要通过应用(App)来改善企业内部的信息流，加强与客户的联系连接。然而，诞生时间不长的IT信息时代也面临着类似于我国社会主义初级阶段的供需矛盾:落后的软件开发生产力跟不上人民日益增长的业务需求。
请点击输入图片说明。
Gartner预测，到2021，应用开发需求的市场增长将至少超过企业IT交付能力的5倍。面对如此巨大的IT缺口，如果没有革命性的“新生产力”体系，很难想象仅仅依靠现有传统技术体系的发展和延续就能彻底解决问题。低代码技术正是带着这样的使命而来，希望通过以下几个方面彻底革新应用开发的生产力，拯救几乎处于水深火热中的IT世界:
提高效率，降低成本&；质量保证
虽然软件行业一直在高速发展，新的语言、框架、工具层出不穷，但是作为从业者，我们不得不承认，软件开发还处于手工作坊的阶段，效率低，人力成本高，质量不可控。项目延迟交付已经成为行业常态，瓶颈几乎都是开发人员(对于机器能解决的问题都不是问题)；优秀的开发人才永远是稀缺资源，也是贼贵；软件质量缺陷始终无法收敛，在线故障频发，导致资金不断流失。
相比之下，经过上百年的工业革命，传统制造业大多早已摆脱了对“人”的强烈依赖:从原材料的输入到产品的输出，中间有各种精密仪器和汽车生产线的稳定支撑，从而真正实现了生产的标准化和规模化。虽然信息化被誉为人类的第三次工业革命，但软件产业的现状远未达到工业化的成熟阶段。
所以，亲爱的程序员朋友，当你一上午都在和前端调试接口，一下午都在和产品强行需求，一晚上都在和自己的bug做斗争，最后睡着了被一系列的报警信息吵醒的时候，你有没有仰望星空说:“我有一个梦想...那总有一天，软件开发可以像工业产品一样批量生产，稳定高效无忧。”现在，不管你是否意识到，这个愿景正在慢慢变成现实。
请点击输入图片说明。
是的，低代码正在将应用软件开发过程工业化:每一个低代码开发平台都是一个技术密集型的应用工厂，所有项目相关人员在同一条生产线上紧密合作。开发的主力军不再是熟悉for循环100种写法的技术极客，而是一群有着满满想法和商业意识的应用创客。有了各种成熟的基础设施，有了现成的标准件，有了应用工厂的自动化流水线，开发者只需要专注于核心的商业价值。即使遇到非标需求，也可以随时自己动手，用最灵活的手工定制(代码)解决各种边角问题。
扩大劳动力的应用和发展
low code(包括零代码)通过让大部分开发工作仅通过简单的拖拽和配置即可完成，显著降低了用户门槛，使企业能够充分利用前述的平民开发者资源。在一些零代码需求的场景下，低代码也可以让业务人员交付自助式应用，既解决了传统IT交付模式下的任务积压问题，又避免了稀缺的专业开发资源被大量简单重复的应用开发需求占用，也让业务人员真正按照自己的想法实现应用，摆脱了交给别人开发时不可避免的束缚。
请点击输入图片说明。
至此，应用开发能力不再是少数专业开发者的专利和特权，未来所需的技能门槛和拥有成本会越来越低，真正实现所谓的“技术民主化”。
在开发过程中加强沟通与合作。
多方调查的结果表明，软件项目失败的一个很重要的原因就是沟通不畅。在传统的开发模式下，业务、产品、设计、开发、测试、运维人员各司其职，各有一套领域的工具和语言。时间长了，容易形成孤岛，导致跨职能沟通困难，效率低下。这也是为什么现在流行的敏捷开发和DevOps都强调沟通(前者是配合Biz和Dev，后者是配合Dev和Ops)，而经典的DDD领域驱动设计也提倡“统一语言”，减少业务和技术人员的沟通不一致。
请点击输入图片说明。
有了低代码，这种情况将得到根本改善:上述所有角色都可以在同一个低代码开发平台上紧密合作(甚至是同一个人)。这种全新的合作模式不仅打破了功能轴，还通过统一的可视化语言和单一的应用表示(页面/数据/逻辑)，轻松对齐项目各方对应用形式和项目进度的理解，实现了更极致的敏捷开发模式，在传统DevOps的基础上更进一步。
统一开发平台下的聚合效应
低代码试图将所有与应用开发相关的活动融合在同一个平台上，这将产生更多的聚合效应和规模效益:
人员聚合:除了上一点提到的各个职能角色的紧密配合，人员聚合到一个统一的低代码开发平台，还可以促进整个项目流程的标准化、规范化和统一化。
应用聚合:一方面，新应用的架构设计、资产重用和相互调用变得更加容易；另一方面，各应用的数据天然互通，平台外的数据也可以通过集成能力打通，彻底消除企业的数据孤岛问题。
生态聚合:当低代码开发平台聚合了足够多的开发者和应用，就会形成一个庞大的、互联的、富有想象力的生态系统，彻底释放低代码的价值。