近几年，低代码平台的概念被反复提及，一度也成为各大技术大会的重点议题。
为什么低代码如此受欢迎呢
19年全球疫情爆发以来，因为居家办公的缘故，许多企业的办公环境被迫从线下转移到了线上，原本线下的工作流程短时间内需要一个线上的IT系统配合精美的界面来完成闭环，催生了许多产业数字化的需求。一般的企业是无法承担开发人员和传统服务器等器材的开销，购买传统的软件服务商的产品又需要付出私有化部署，驻场实施等额外成本。
这时候支持拖拉拽快速创建页面，可视化配置流程的低代码平台一下子成为了成本与功能性方面俱佳的选择，国内外也涌现了大量的低代码平台服务商。
这张图片有一点老了，后来很多云厂商推出的低代码平台没能包括在内，主要是为了体现平台的“多”。从这张图可以看出来，其实已经有很多耕耘垂直领域的产品了。
但是“低代码”的概念却不是近几年才刚出现的，它的历史可以追溯到20世纪70年代，当时的软件工程师们开始尝试使用组件化编程的方法来提高开发效率，低代码平台则是在这一基础上发展而来。
4GL
1970-1990的时候，出现了4GL（Fourth-Generation Programming Language第四代编程语言）的概念，第四代与第三代的编程语言代表可以看下面这张图：
熟悉这些语言的读者能大概看出来3GL和4GL的主要区别吗？
下一篇公布答案吧（开玩笑的）
二者的主要区别其实是指令式编程和声明式编程，以C和SQL的对比为例，C当中定义一个变量需要指定类型，int a = xxx这样，这个int就不是很自然语言，在SQL当中select, update指令就很接近自然语言的描述了。
James Martin的一句话
随后时间来到了1982年，James Martin写了一本书，书名叫做《Applications Development Without Programmers》，在这本书中提到：
4GL technologies (such as RAMIS and FOCUS) open up the development environment to a wider population and enable non-programmers to create applications themselves.
《Applications Development Without Programmers》
翻译过来就是：
4GL 技术拓宽了开发人员的范畴，使得这部分人员可以在没有编程人员的情况下自己创建应用。
这个今天听起来稀松平常，放在当时可是相当超前的。他写了书，但是没有实现，也被我编进了简史，好家伙。
RAD
1990年代的时候，又出现了Rapid Application Development (RAD)-快速应用开发的概念。在RAD出现之前，软件开发普遍采用瀑布流模式进行迭代，每一个项目周期非常冗长，从需求，设计，实现，到项目的验证和维护，都需要经过详细的设计和全盘思考，保证能满足所有的需求。
但是环境是不断变化的，瀑布模式导致变更需求很不方便（作为开发，个人表示很向往这种项目方式，虽然不利于业务快速迭代，老板不喜欢）。
RAD模式把需求方和实现方拆开，使得两部分可以分别运转，这样需求方就可以不停地梳理需求，系统设计和实现的部门可以排期不停的接需求，真的很高效呢！！这跟我们今天项目管理方式很接近了（万恶的资本主义）
但是当时实现了RAD的几个平台也有其局限性：
-
受限于运行环境与平台，比如Microsoft Windows for Visual Basic and Delphi, Oracle application server, and a database for Oracle Forms。
-
多人协作比较困难，缺少协作功能，彼时还没有云的概念。
-
性能差，大部分平台是用java开发的，运行的时候需要占用大量资源（当然，现在的Java虚拟机性能已经强太多了）
此外，RAD把需求部门和设计/实现部门拆开，使得两者很难用同一种语言进行交互，其实沟通的效率不高，也无法准确地对齐需求的意图和细节。
那么就有人想了，我能不能设计一种语言，让项目全周期的人都能无缝对接呢，哪怕是需要一点学习成本。
MDSA
这不，2001年的时候，模型驱动的软件开发（Model-Driven Software Development -MDSA）就流行了起来，项目中涉及到的所有的人员统一用模型来描述需求和实现，这样就极大提升了沟通效率，还方便需求文档千秋万代反复诵读。我们今天所熟知的UML统一建模语言，BPMN流程建模都是那个时期兴起的，这俩直到今天都还是应用甚广，如果你还不会熟练画UML，那就很难清晰描述你的设计思想（不会画就要告诉我，我出教程）（当然，如果受众看不懂，那真的是束手无策呢）。
今天我们在低代码平台中使用的DSL，JSON schema其实也是属于模型的范畴，编辑端和渲染端只有约定统一的模型，才有可能实现二者的无缝对接。规则与流程也需要设计统一的模型才能实现规则引擎和流程引擎。
移动端
2007年之后，移动端应用井喷式发展，这个时期，APP的开发工具都提供了拖拉拽生成界面的功能，XCode(iOS开发)和Android Studio都可以快速的构建页面（但是需求实在是...太灵活了，我了解到的页面组件，其实都是得手撸）。很多简单的应用可以快速开发完成，这使得软件生态的进入门槛大大降低，昨天我刚看到一个Tim Cook来到中国与一些APP开发者见面的视频，看到其中有很多非程序员出身的开发者也创造了体验非常优秀的产品，优秀到苹果CEO都要见一见的程度。
Low-Code
2016年之后，Low-Code（低代码） & LCDP（低代码开发平台）的概念又一次火了起来，起名字的艺术啊同学们。一个“真正”的低代码平台的应该包含以下部分
“真正”的低代码平台的构成
-
可视化视图编排
-
可视化模型配置（审批流，事件流，数据流）
-
应用生命周期管理
-
底层提供的开箱即用的微服务（现在这个概念进化为云原生了）
-
持续集成和持续交付
用这个标准看，其实很多平台是“伪”低代码平台，但是，这重要吗？窃以为要能成事儿的才是好工具。
疫情点燃低代码
2020年之后，众所周知，疫情侵袭全球，低代码平台在数字化转型，办公流程无纸化，场景线上化等场景中大放异彩，几乎所有人都被领导问过能不能用低代码平台提效。也会有很多人说不够灵活，无法满足业务频繁变动，也有人说灵活性太强了，使用的方式就很抽象，还不如手撸代码，二者成本差不多。
你怎么看待低代码平台呢？
由于本人的日常开发中要接触大量的管理后台，所以最近我也在痛苦地深度使用低代码平台。
需要将自己成熟的组件库适配接入到平台
需要熟悉平台提供的种种能力的使用方法
需要梳理项目迭代的规范
需要考虑手撸代码与低代码生成页面的无缝结合
需要考虑私有化部署的方案，防止平台有一天搞不下去。
坑，真的很多，累，是真的累，快乐，攻克每一个难题的时候也是真的快乐。
共勉，各位！！
欢迎关注我的公众号：方始终
