少写代码，用更便捷的方式开发程序

关于低代码的误解很多，很多人对低代码刚出现就各种穷追猛打，实际上并没有深刻理解低代码的目标人群和使用效果。

尽管我对低代码的使用期望更接近一开始的定义，也就是用低代码的方式更快更好地开发应用。就是通过少写代码，用更方便的方式开发程序。（前提是不损失任何功能或者尽可能少地损失）

现在的低代码，算是喜欢的喜欢、讨厌的讨厌，喜欢的自然觉得给自己省下了时间，提升了效率；讨厌的可能是之前被什么产品坑过，或是天生就讨厌这种低代码，总觉得是某些商家专门拿来牟利的利器，或是影响自己的职业发展。

我个人对低代码的态度没有喜欢和讨厌之分，单纯将它做为一个工具来使用，低代码好用，也有适用的范围，超过这个范围用别的方法就好，所以不像网上两拨人争论的那么厉害。

比如说我要开发一个网页，做一个工具表单，做一个快速的程序验证想法，用低代码的方式做就是更快。如果要刷算法，嵌入式系统和硬件级编程，那低代码就是做不了，乖乖用回 C++，就这么简单。

其实一个专业低代码比大多数人想的技术构造要复杂，要做出来也并不容易。

首先要保证产品本身的架构的灵活性，现在无论是前端还是后台，还是云计算，技术迭代的速度都非常快，需要设计一个通用的架构，保证有新技术出现的时候可以快速迭代进来，这点非常重要。

国外的低代码龙头 Outsystems 更新 20 多年，一直在适配近年来的各种前后端技术，就是因为一开始选用的技术框架太过古老，这艘大船想要调头就难得多，但是没办法，只能修修补补接着做。

其次，图形化编程语言本身的设计和现有编程语言的转化，也是一个难点。图形化编程语言的 AST（抽象语法树）如何设计？语义空间（关键字）有多大？如何才能生成流行且大家熟悉使用的编程语言和代码框架？

后台数据库以及后台资源如何接入并保证高可用？外部系统例如 3D、2D、物理引擎如何接入？如何高效渲染？这些都是很棘手的问题，而且很多问题并没有标准答案，都需要独立创新和研发。

就拿 AST（抽象语法树）设计举例，前端的 AST 和后台显然是不一样的，例如后台需要转码 Java，而前端需要转码 vue/react/dart 等，那 Java 是直接采用 Java 原有的 AST 还是重新设计一种？

国内 iVX 的团队就是重新设计了一种 AST，用来生成 Java AST，再转码 Java Code。这是种很聪明的做法，效果很好，体验也很流畅，稳定，但这也是 16 年不间断迭代研究出的结果，可见这个领域跟大部分人想的“速成”还是有些差距。

现在关于低代码是给谁用的，有两种主流的观点。一种认为低代码是给工程师用，目标就是让这些开发软件的熟手把软件快速做出来；一种认为，低代码是给业务人员适用，目标就是降低门槛，不占用稀有的开发资源。

现在低代码存在的两种主流形式：模型驱动和表单驱动就是这两种观点的最好体现，模型驱动为了开发人员适用，表单驱动就是给业务人员。这两种观点也没有错，但我认为还遗漏了一种方式，那就是开发人员跟业务员混合开发的方式，这点我会在以后专出一篇文章详细谈。

低代码说到底还是个工具，有没有用取决于使用它的人，软件开发的历史已经有七八十年了，但编程的方式一直没有发生太大的改变，这对于一个技术快速迭代的领域来说本来就显得奇怪。特别是撰写重复的代码上，我个人觉得是没有必要的，完全可以优化。

我希望大家保持一种更开放的心态，对于新技术，先不要急着下定论，最起码在自己了解一个新事物前，收回自己的固有看法才是重要的，再多的评测和言论都不如自己亲自体验下，有用的东西为我所用，没用的东西置之不理，这样就足够了。