低代码的前世今生
软件开发从机器语言时代开始，历经以汇编语言为代表的低级语言时代、以Java等面向对象的语言为代表的高级语言时代、以Oracle等为代表的第四代语言，逐渐发展到现在的低代码/零代码时代。低代码编程技术的出现，将软件开发的复杂性留给了开发平台的研发，致力于减少影响软件开发效率的不确定性因子，如人员来回沟通、业务与技术的Gap、人员技能差异、新技术复杂集成等，以期达到提升开发效率的目的。相对传统开发方式而言，低代码在软件开发全流程中的差异点大致如下：
AppCube低代码：元数据驱动，前后端解耦
AppCube 是元数据驱动的全云化一站式程序低代码开发和运行平台，支持应用构建、代码编写、编译、测试、发布、上线。平台提供自定义创建或扩展数据模型的能力，提供拖拽式、图元化编排业务逻辑接口的能力，提供基于H5开发前端页面的能力，不提供开发手机原生app的能力。专业的开发者可以使用TypeScript语言辅助开发。
使用AppCube进行应用构建的步骤，大致分为创建应用项目、设计界面、绑定数据模型、编排业务逻辑和测试发布。
完成了应用开发之后，通常需要安排测试和商用运行部署。为保证数据安全，不中断在网现行业务，AppCube为开发者提供开发、沙箱、商用三套环境。
百闻不如一见：应用开发实操演示
接下来为大家分析该应用涉及到的用户角色、相关业务交互流程和关键的交互页面，并交待了使用AppCube进行该应用开发的工作顺序。
根据 Gartner 的官方预测：“到 2025 年，70% 的新应用将由低代码或无代码技术完成开发”，如何看待未来低代码运用的广泛程度？
上一期也有类似问题。当前低代码其实是面向专业软件开发工程师的，不是面向专业人员的。因为使用低代码平台还是需要用到比较专业的开发逻辑、开发思想，普通的业务人员还不掌握这些知识，并不能开发出真正的具备复杂性的应用。Gartner认为零代码是低代码的一部分。部分业务人员也可以用低代码平台构建出相关的应用，但这部分业务人员通常也受过软件开发相关的教育和训练。国内现在零代码比较多，大家倾向认为业务人员可以使用零代码去开发，这个现象也确实存在。但就像我上期说的，我们看待低代码要回归理性。应用中要用到的函数、算法，尤其是比较核心的算法，不适合使用低代码开发。低代码更适合以微服务的方式去“调用”这些能力，而不是去“开发”这些能力，否则效率会比较低下，不建议。关于70%这个数字，个人是这么看的。这里面说的低代码是一个理念，并不是只有低代码平台开发出来的应用才叫低代码。在应用开发过程中，符合低代码这一理念的，也可以称作低代码应用，比如在开发时使用了封装好的东西，做了配置式的开发，或者用了已经抽象好了的底层的业务逻辑，我认为都属于低代码的范畴。基于这样的理解，我认为“到 2025 年，70% 的新应用将由低代码或无代码技术完成开发”这样的预测是合理的。未来低代码重点还是应该聚焦软件开发工程师，零代码在业务人员当中使用。国内零代码的发展情况比国外稍微好一些，它释放了软件生产力，未来的前景是好的，不过离真正普及还需要一定的时间：刚开始需要低代码去开发可复用的组件、逻辑，当这些可复用的单元越来越成熟，再由业务人员去进行拖拽式开发，这样才会有一定发展。先低代码打好可视化的基础，然后零代码，应该是这样的过程。
使用低代码开发出的系统，性能会不会很差？低代码开发出的系统，耦合性是否过强，导致后续维护困难？还有就是作为开发者关心的测试问题？
AppCube平台部署是具备弹性伸缩能力的，平台也会提供测试机制去保障相关的性能，华为云在这方面是比较成熟的。AppCube最开始为电信运营商的计费、CRM等系统定制提供服务，那些系统对性能的要求也都比较高。一般来说，选择了低代码平台之后，开发出来的应用确实会对低代码平台有一定的依赖。但就应用本身来说，用AppCube低代码开发出来的应用前后端是解耦的，这方面不会有问题。至于测试，AppCube有提供沙箱环境，这样应用在正式上线之前可以进行充分测试，提前暴露可能存在的功能问题。
如果用AppCube开发一套系统，例如停车场收费系统，大约需要多少费用，和市场上已有的系统相比有什么优势吗？
停车场收费系统主要是计费的业务，这类业务系统需要大量的数据处理，在性能方面也对后端的要求是非常高的。市场上现有的系统大多是传统全代码方式开发的，使用低代码，可能是对老旧系统做改造，或者是全新开发。如果是全新开发，那关于计费的核心算法的部分，最好是把算法用传统方式开发好，然后以微服务的方式接入到低代码当中。如果用户是第一次使用低代码平台，可能会感觉跟全代码的方式很不一样，甚至还要花很多时间去学习和熟悉低代码平台的使用，并不一定能感觉到低代码到底给他带来多大优势。但随着对平台的熟悉、随着系统计费规则、逻辑不断扩充，低代码的优势会越来越显现出来。随着应用资产沉淀越来越多，低代码带来的效率提升效果越明显。如果是在传统系统做改造，情况类似。我们不要认为引入低代码可以解决一切问题。计费系统比较复杂，里面的算法开发目前还是适合全代码方式，业务逻辑之类的可以使用低代码去编排复用，PC端、手机端等不同终端的页面也可以用低代码去开发，这样是可以提升开发效率的。综合来说，开发一套计费系统，要根据全代码和低代码的特点去将两者结合使用。
