如何理解低代码的兴起

这篇文章主要讲解了“如何理解低代码的兴起”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“如何理解低代码的兴起”吧！

低代码是一种近些年兴起的企业软件快速开发技术和工具。借助低代码使用者无需编码即可完成企业应用的常用功能，少量编码扩展出更多功能。低代码凭借低门槛、高效率和易集成等特性，被越来越多的软件开发团队青睐。Gartner预测，到2024年四分之三的大企业将会使用至少4种低代码开发平台，用于信息化应用开发。届时，65% 的应用开发将通过低代码完成。

面对低代码的兴起，程序员们有几种不同的心态：一种是轻视的心态，认为低代码技术不能登大雅之堂，只是给初学者使用的雕虫小技，解决不了复杂的技术问题；一种是恐惧的心态，担心低代码会取代专业开发者，并淘汰大部分程序员的工作；一种是抵触的心态，认为低代码平台是个黑盒子，很危险，有很多不稳定因素，未来的迭代升级无法保障；还有一种失落的心态，认为有了低代码开发工具，程序员再不需要掌握高深的技术，工作中已经失去了成就感。

作为一个资深程序员，通过这两年对各种低代码平台的了解，我想就低代码平台的兴起谈一谈我个人的看法。

低代码平台的代表企业包括国外的OutSystems、Mendix等，国内的企业有奥哲网络（氚云）、ClickPaaS、瓴码、宜创科技、炎黄盈动、数式科技、轻流、搭搭云、黑帕云等低代码创业公司，以及APICloud、明道云等延伸或转型到低代码领域的创业公司，以及大型企业旗下的业务模块，如帆软的简道云、阿里的宜搭等。可以将低代码开发平台按照技术路径架构分为三类：

一类是基于表单/引擎驱动的模式，通过建立多张表单，使用流程串联，定义报表输出方式，构建表单类轻应用。该类模式的技术壁垒不高，主要支持开发表单类应用，场景有一定局限性。更适合简单短信项目，不适合长期的循环迭代产品的开发，尤其产品要面对多样性需求，必须具备高配置属性的时候。比如表格展示，同一个流程不同职位看到的表格都是一样，涉及到敏感信息不能区别展示，无法实现千人千面。这类平台有：轻流、搭搭云、阿里的宜搭、宜创科技等。

一类是基于aPaaS平台模式，包含多种具体的技术手段和路径，例如模型驱动、代码生成、可视化编程等，底层技术涉及云原生、元数据、多租户等。该类模式的技术壁垒较高，颗粒度更细，复杂度、灵活度更高，能够支持广泛场景的复杂应用开发，具备服务大客户和中小客户的能力。这类模式在面对复杂场景时，仍然需要编写逻辑代码。特别是在面向高并发应用场景，需要投入大量的后端软件开发。这类平台有：OutSystems、Mendix、奥哲网络（氚云）、ClickPaaS、炎黄盈动、数式科技、黑帕云等。

还有一类是基于aPaaS+iPaaS平台模式，这类低代码平台不但具备可视化模型驱动、代码编译自动生成，无论前端组件还是后端业务逻辑都能细粒度搭建，实现高度复杂、高度灵活的应用场景。这类平台的iPaaS部分属于领域驱动的设计模式，其核心概念：域、子域、领域实体、值对象、领域服务、领域事件等是天然的图形化解决复杂问题的表达模式，面对任何复杂应用场景都能支撑aPaaS的可视化搭建，并能可视化集成各种业务应用，适应任何高并发的应用场景。这类平台有：瓴码PaaS。

每种低代码平台都有其存在的价值，第一类平台虽然使用范围较窄，程序员们也不要对其嗤之以鼻的轻视，这种平台特别适合不懂软件的业务实施人员使用，能够快速响应业务简单调整的个性化需求；

对于复杂业务场景的应用实现，虽然第二类平台可以通过可视化搭建大部分功能，很多数值模型、业务流程模型的搭建仍然离不开专业程序员逻辑抽象能力，特别是很多复杂算法逻辑、以及后端系统架构的搭建还是要使用到源代码实现。

即使是第三类平台能够完全抛开源代码通过图形化搭建任何复杂应用，同样道理，开发人员必须有面向对象的逻辑思维，以图形化的形式去构建领域实体、值对象、领域服务、领域事件，通过连线去建立这些要素的逻辑关系。

其实所有这些平台只是一种工具，给程序员解决了以下几个问题：

1、提供了大量常用标准组件和函数；

2、以图形化方式替代了原先的计算逻辑；

3、以图形化方式建立各种数据模型；

4、以图形化方式建立各种业务对象；

5、以图形化方式实现了界面的布局；

6、以有向连线的方式为计算逻辑和业务对象建立关联；

7、实现基本语法逻辑的自动识别。

从而把程序员从代码式的逻辑中解放出来，以图形化更直观的方式展示所有图灵完备的机制。还能自动识别大部分语法逻辑，减少BUG数量。并通过组件标准接口的定义提高组件复用的效率。让软件开发效率有一个革命性的提高。所以，完全不必担心程序员的工作会被淘汰，低代码只是专业开发者手边更趁手、更高效的工具罢了。

又有一种态度认为这些低代码开发平台是个危险的黑盒子，他们担不起在无法控制的“黑盒”上开发关键任务带来的风险，比如平台不稳定怎么办、开发进度过半发现有问题无法解决怎么办、升级迭代无法实现怎么办等等。首先，这种逻辑看起来没毛病，所以，我将花更大的篇幅来解释为什么这种抵触是不合理的。

首先，低代码的黑盒子是在开发者熟悉的技术栈上运行，而这些技术栈本身和低代码类似，也经历了被逐步认识、喜爱、鄙视并再次喜爱上的过程。比如瓴码低代码开发平台就是的后端底层技术架构采用c++，后端业务逻辑采用NodeJS，前端完全使用JavaScript，安卓端和IOS端使用Flutter。这些技术栈保障了低代码开发平台自身的稳定性和可靠性。

更重要的是，所有低代码平台都已经经过内部的反复测试，并有了大量应用实践，有足够的成熟度才会推向市场。

事实上，我们都爱“黑盒子”，尤其是可以帮我们大幅节省时间的黑盒子。Java及其姊妹语言Scala，Groovy，和其他语言一样依赖于开发者中最受欢迎的黑盒：JVM；而C#、VB.net依托在.net Framework上才能运行。那么，为什么我们会信任JVM、.net而不是低代码呢？因为时间可以为这些平台证明。

21世纪初，.net在诞生时也受到开发者社区的严格审查。但在看到它年复一年地顺利运行后，信任度增加了。开发者知道C#和.net仍然会存在很长一段时间，而微软将继续支持这两者。我不知道微软将会如何执行我的C#，但是我依然信任着它。就像我相信V8引擎执行我的JavaScript，JVM运行我的Java一样。当然，我也不能忘记曾经依赖的其他著名的黑盒：Spread、KendoUI、ActiveReport等前端控件。正是因为有了这些控件，我们开发应用的效率得到了数倍的提升。如果你从事过程序界面的开发，我相信你一定会和我有同感。

事实上，低代码并不是一个这两年横空出世的技术，只是近些年更受媒体关注而已。十几年来，已经有太多的案例能向你证明这个“黑盒子”的真实实力，应用场景从MES、ERP到SCM以及SCRM，终端平台也支持PC浏览器、APP、企业微信和钉钉。所以，也许是时候给低代码这个不算很新的黑盒子多点信心了。

另外，我们程序员中还有很多技术控，喜欢钻研各种高深技术，确实通过技术的积累某方面讲能够提高技术人员的价值。但有很多技术已经大众化、平台化了，程序员们就大可不必去重复造轮子，只需要顺手拿来用即可。

低代码平台就是一个屏蔽了很多复杂技术的大平台，例如瓴码PaaS系统，实现了基于领域驱动的微服务架构全部技术，包括：业务流引擎、分布式事务处理、分布式数据交互、异地多活的备灾处理、高并发的负载均衡、安全与认证机制、微服务的健康检测等等。程序员们只需要托拉拽、画图连线、简单配置，即可调用平台提供的技术接口，轻轻松松就能解决以前需要技术牛人花大力才能解决的问题。

那么，是不是有了低代码平台，开发工作就不需要技术牛人呢？并不存在这种问题，只是技术牛人的关注重点要发生转变，再不用象以前关注系统端的技术，而更关注业务端的抽象能力，例如：如何把一套业务需求抽象出领域实体树，定义域、子域之间的关系，以及每个领域实体内的值对象、领域服务、领域事件的定义。对业务的理解能力、对领域驱动的知识积累、对领域实体的抽象能力、对算法的逻辑思维能力，一样可以把技术牛人发挥到极致。当技术牛人制作完一套业务系统的技术图纸，以前需要996的上班几个月才能完成的系统，使用低代码平台后短短几周就被你攻克，就像摩天大楼的总设计师一样自豪感悠然而生。总之，技术牛人是不可替代的。

程序员们除了低头编代码之余，也要学会抬头看路。时代在发展，我们不但要紧跟时代步伐，有时还需要有比别人更长远的眼光，时时保持一颗好奇的心，以及不断学习的热情，去探知新鲜事物。而不是不加思考、不去了解地抵触或恐惧新鲜事物的出现。大部分人因看见而相信，只有很少部分人是因相信而看见。希望更多程序员们敢于相信，来迎接软件生产力的这次大变革。

开始使用低代码工具，乘着软件开发技术的发展趋势，从更高效率的在开发中获益吧。

感谢各位的阅读，以上就是“如何理解低代码的兴起”的内容了，经过本文的学习后，相信大家对如何理解低代码的兴起这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！