无代码平台，完成业务的最后一公里

当今的IT行业，相比十年前有了长足的进步，云计算、大数据、人工智能、物联网、中间件、中台、PAAS、各种先进算法等等概念逐步浮出水面和落地， 各种编程语言、框架、工具如雨后春笋层出不穷，纵观整个计算机行业的发展历史，冯诺依曼体系结构的提出使得现代计算机得以实现，计算机不再是计算器，计算器只能进行数值运算，计算机可以根据输入的数据进行 逻辑计算，这是巨大的进步，有了逻辑，就有了解决领域问题的基础，现实世界的领域问题归根结底是逻辑问题，所以计算机的诞生自动化的解决了人类许多领域的领域问题，比如在线购物（电子商务）、企业管理（ERP）等等。

我们刚才提到计算机可以根据数据进行逻辑计算，这其中的数据就是我们所说的程序，程序的发展也有一个进化过程，从最开始的电线编排，到接下来二进制编码写到打孔纸带上，再到后来的汇编语言这种方式完成程序的逻辑编写，让机器读取运行，这种编程模式是面向机器的编程，它是依赖硬件的，硬件的运行结构和指令发生变化就得重新编写程序，非常低效，可移植性很差，问题领域稍微复杂就会让程序变得非常复杂难以维护，这个时候一些高级语言诞生，比如C、Basic等等，这些语言是面向过程和逻辑的且是线性的，非常符合人类的思考模式，这些语言通过自带的编译器将高层语言编译成指定计算机硬件机器指令让计算机运行，到现如今它依然是所有高级语言的底层逻辑，这个时候程序和计算机硬件解耦了，人们解决领域问题从以前要关心机器和逻辑到现在可以专注于如何实现逻辑，这一个里程碑的进步导致众多语言和编译器、虚拟运行器（例如JVM）的诞生以及到现代操作系统诞生。人类要解决的领域问题越来越大越来越复杂(现代的ERP系统已经是一个规模庞大极其复杂的系统)，试想一下通过C语言去实现这些系统，这种面向过程和逻辑的语言通过一条一条的逻辑语句去实现这些领域问题，代码的规模得多大，人类几乎是不可以维护的，并且极容易出现BUG，这就是软件开发历史上所谓的软件危机，这个时候面向对象的方法被提出，通过面向对象的方法去分析和抽取领域问题的模型来提供计算机运行，领域问题就变成了如何分析和抽取计算机模型的问题，于是一些面向对象的语言诞生了,例如我们现在常使用的JAVA、C#等等，面向对象的方法更能真实反应现实世界的对象和问题的复杂性，这种面向领域问题的编程模型更容易去实现更复杂的业务。这其中我要强调的一点是，语言的发展史不是取代的过程，是叠加的过程，面向对象并没有取代面向过程（C语言）和面向机器（汇编语言）这些，面向对象依然需要过程逻辑，依然需要编译运行器将其编译成机器代码输入给计算机执行。下图是编程语言的演进过程：



前面讲了那么多，似乎跟无代码平台没有关系，前面都是前人总结的经验和提出的解决方法，从历史去发现事物的发展规律和发展逻辑是我们常用的手段和方法，从这个底层逻辑出发，所以笔者前面讲了一下计算机和编程的发展历史，让接下的观点和思考有一定的依据（这里更多是思考，不是总结和经验）。做过系统设计的朋友都知道，在使用面向对象进行系统设计的时候，我们经常会用到UML（统一建模语言）对系统的对象进行建模并建立对象之间的关系，然后程序员根据UML模型图将这种图形化的表达设计语言翻译成JAVA、C#等面向对象的程序代码，这过程中是由程序员来完成的，那模型是由谁来完成，这里通常是架构师和系统分析师,它们肯定要理解和深入了解问题领域才能设计这些对象模型，否则如何解决领域问题，你都不了解商品、订单、物流这些领域对象怎么能设计出合理的电子商务模型呢，这里需要就是一个理解业务的人去做这项工作（不一定是架构师和计算机专业人员，对业务足够深入和理解面向对象，并学会使用UML建模工具的人都可以做），那为什么是UML，UML具备那些特质了呢，第一最重要的是它是标准的语言（不是方言，方言各说各话大家听不懂），第二是它是图形化的表达，有句话怎么说来着能用图的就不要用文字（机场指个路都用箭头加文字呢），一图胜千言，有了这个逻辑，我们是不是可以想象一下，能不能发展出一种语言，例如图形化表达语言，UML算是一个尝试，它解决一部分问题，但是需要人工翻译成JAVA等文本语言代码（有些UML工具可以自动生成代码，但是这些代码通常是需要修改调整的），那我们是不是能发明一种图形编程语言加上编译器和运行器，直接可以运行这些定义的图形语言，其实已经有LabView这些尝试的案例了，UML是一种统一建模语言，它是一种标准，大家都共同遵守标准都能理解，那是不是笔者刚才讲的所谓“图形编程语言”要制定一个标准呢？前面说过新的语言诞生并不是取代，是叠加，这个“图形化编程语言”是不是吸收面向对象的特质，将对象模型图形化（UML也是如此），对象之间的交互图形化（UML也是如此），它既解决人难以理解和维护文本语言的问题（使用门槛大大降低，可以直接由能理解业务的人去写代码，解决程序员和产品经理沟通鸿沟问题），又不会丢失面向对象提出的通过对领域问题的分析和抽象来实现复杂业务的方法。那是不是我们所有的基础设施例如操作系统、中间件、框架、中台用这种图形化语言重写，笔者的观点并不是，纵观软件的开发历史从来也不是，笔者一直强调的叠加，操作系统解决底层逻辑和基础设施问题，中间件解决更上一层的问题，中台越来越接近业务，但是中台没有解决业务的最后一公里问题，最后一公里需要基于中台进行组装和二次开发最终形成能交互的软件交付到客户和使用者手中，就像我们经常听到的一个概念，物流系统的最后一公里问题，整个物流系统通过基础设施建设（各地建仓库和物流站）快速运转，今天在线订购的商品，明天就能达到你所在城市或者区域，但是商品没有到消费者手中，最终商品要到家到消费者手中才是完成了整个物流逻辑，所以云计算、大数据、人工智能、物联网、中间件、中台、PAAS、各种先进算法能让复杂需求更够快速得到满足，但是他没有形成用户最终交付产物,所以回到“图形化编程”，它是一种无代码的编程手段，笔者认为定位于解决业务最后一公里问题更加合适，它可以嵌入运行在各种基础设施（操作系统、浏览器、嵌入式设备）和编程框架（Winform、WPF、Vue、Spring、Spring Cloud）中，这些基础设施和编程框架本质上提供了编程模型和入口让程序员去写业务代码，例如Winform事件模型，程序员只要要将自己的代码块挂载到相应的事件即可完成各种应用逻辑，不用过分关心Winform这种编程模型的底层逻辑和依赖是怎么样的），基于以上思考，“图形化语言”更像是直接面对更能解决领域问题的劳动者（过去是程序员现在是业务人员）去解决领域问题（劳动对象），并依附于这些框架和基础设施，无处不在（想象如果能像UML标准化，它的生态会非常大，所有需要解决业务最后一公里的基础设施、框架、中台都能运行它），解决业务系统最后一公里交付到客户手中。我看到网络上有一种观点，无代码不能解决复杂问题，我想表达是无代码从来不是要解决复杂问题，我相信很多聪明的人和伟大的公司能很好的解决复杂问题（框架、算法、中间件、中台、新型硬件等等），我们只解决一个问题那就是由理解业务的人（劳动者）快速的把软件（劳动对象）交付给最终的用户，就像整个庞大的物流系统一样，建仓库和物流站等基础设施我们干不了，我们只充当一个快递小哥角色把东西送到用户的手中。如果把无代码平台要解决的问题定位错了，你就会不自觉的否定它和排斥它。下图表达是一个编程的核心要素：



以上所有观点和思考都是基于软件的历史发展规律和要解决的问题，并且笔者也做过小小的理论研究和实践，这篇文章没有讲如何具体实现无代码平台，只是提供了一个思路并畅想了它未来的生态和定位，是不是有点激动和兴奋？