低代码是什么？

首次 由 Forrester Research 研究机构提出低代码的定义，即利用很少或几乎不需要写代码就可以快速开发应用，并可以快速配置和部署的一种技术和工具。让计算机彻底工具化成为开发人员致力达到的圣杯。

从计算机发展历史来看，每个阶段的低代码定义都是不一样的。最开始，使用高级编程语言 ，FORTRAN 去编程，替代机器码编程，FORTRAN 中的数学表达式就是“低代码”。后来编程开始围绕数据来展开，SQL 使得业务人员不用写代码就生成自己的数据报表，也被认为当年的低代码。根据历史规律，这类“低代码”最终都演变成程序员的一个工具。这次流行的原因也一样，微服务的发展，使得通过更简单、更低成本的方式把已存在的微服务串联起来，形成新的功能成为可能，借此来降低新功能研发和创新的成本。

低代码的有哪些分类？

低代码可以粗粒度地分为三类：

1. 脚本化。这类低代码产品最终会演变成程序员的工作，甚至引发新一类程序员的出现，而它本身则从低代码退化成为真正的代码。

2. 自动化。企业内部仍然存在大量的人工操作和流程。企业很难关注这些流程，加上想要自动化这些工作是很难的，所以，在行业中大多是针对个人工作流的自动化工具，这种服务于个人生产力的低代码，既不会对行业造成影响，同时又有很明确的市场需求，但由于不赚钱，进入这个领域的人非常少。

3. 以降低程序员门槛为目的，想要说服企业使用便宜的人力成本去干活的低代码（甚至是无代码）平台。实际上是使用表单去绘制工作流，然后在工作流程的每个节点上配上表、企业流程和 OA。

低代码平台是行业毒瘤？

首先，企业研发团队需要改变原本的工作模式，存在巨大的变革成本。

其次，工具低代码平台预设的使用人群永远是初级、入门的人。然而低代码工具平台真正的需求应该是帮助开发人员需要提升效能的工具，进行流程有效的自动化，而不应该是帮助小白来入门行业。

《人月神话》里也提到过图形化编程，预言的是 10 年内不会有突破性进步，然而过了 34 年的今天也没见明显进步，在他的文章里告诉我们流程图最早是给汇编语言用的，因为汇编代码里都是跳来跳去的，看着容易晕，有这样的图可以看起来更清晰： 

低代码平台的困境

低代码平台能解决什么问题呢？首先按《人月神话》里的说法将软件开发进行分类：

所有软件活动包括：
根本任务--打造构成抽象软件实体的复杂概念结构。
次要任务--使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

「根本任务」指的是实现某个功能需要使用的算法，「次要任务」指的是使用怎么实现这个算法。「根本任务」无法解决，因为它就是需求本身，唯一解决办法是砍需求。低代码平台主要解决的是「次要任务」，用更简化的方式来实现同样的功能，

低代码平台的难点是什么？需要同时满足易用性和灵活性，以低代码平台中必备的可视化页面编辑器为例，要怎么实现页面布局？主要有三种做法：

1. 基于 flexbox/float 方式来布局，这种方式灵活性强，但牺牲了易用性，需要使用者至少懂点 css。
2. 基于绝对定位来布局，这种方式易用性强，想拖哪就拖哪，但又失去了灵活性，要支持多分辨率就得手机和 PC 单独编辑，而且不好实现根据内容自动撑开高度。
3. 提供水平/垂直分栏的容器，通过它们组合来实现各种布局，这种方式处于上面两者之间，灵活性和易用性都不突出，只适合用在移动端或后台类的页面。

除了布局，还有另一个问题是要不要支持自定义 class？不支持的话灵活性差，改个字体所有地方都要配一遍，而支持又导致易用性差，不了解 css 的用户会发现改了一个地方影响到别的了，要想不一样还得新建一个 class，有理解上的成本。

前端如何低代码？

前端开发的主要工作是界面、交互和业务逻辑。可视化页面编辑器主要用于制作静态原型，或者官网及落地页，很少用在前后端交互比较多的页面中，因为动态数据难以在可视化编辑器里展示，比如条件渲染？所以界面开发效率提升主要靠 UI 组件库。

低代码平台不适合用在面向用户的产品中。但在企业应用中情况就不一样了，这些应用页面相似度更高，大部分是表格表单，而且更重视功能而不是个性化展现，因此跟容易实现复用。

然而 UI 组件库强依赖开发，并不能算低代码，要想低代码必须进一步降低成本，比如那种用配置化的方式

1. 突破前端圈的易用性。

 UI 组件库易用是有前提的，至少得会 JavaScript，而如果是配置化的平台，使用者绝大部分不需要了解前端，而UI 库必须用代码来连接各个功能，比如数据的加载和绑定、事件的处理等，这些功能难以使用可视化编辑器来实现。

2. 完整的界面解决方案。

UI 组件库一般只作为页面中的一部分，而低代码平台所要实现的是完整页面的配置化，可以通过配置实现交互功能，还包括富文本编辑器、条件组合等组件。

业内主流的低代码生成方案有两种，一种是通过训练神经网络，从图片或草图直接生成代码，以微软sketch2code，imgCook3.0为代表

imgcook 原理

从设计稿文件中提取到描述这个设计稿文件的 JSON Schema，使用设计稿协议、程序算法和模型算法来计算、分析和识别，将这个JSON Schema 转换成一个具有合理的嵌套布局结构和代码语义的 D2C JSON Schema。然后再通过各种不同的DSL 转换函数将 D2C Schema 转换成不同类型前端代码，比如 React、Vue 等等。流程如下：

• 设计稿转DSL视图树（UI2DSL）：将设计稿转化成平台无关的DSL视图树。
• 视图树转代码（DSL2Code）：将DSL视图树转化成Flex布局静态代码。
• 业务信息绑定：提供可视化配置工具，绑定后台数据、业务逻辑、以及曝光/点击等埋点逻辑。

其中程序算法是指通过有限的规则计算来自动的识别设计稿，例如可以根据每个图层的坐标、宽高等信息来计算出它是不是一个循环结构，可以根据字体的大小和字数来判断这个文本是个标题还是提示信息。

对输入到算法里的设计稿，进行预处理——可视化干预，将不标准的设计稿转化为标准的图层信息后再输入给算法。

但这种有限的判断的规则是没办法解决大多数设计稿中的问题， 可以通过机器学习模型来智能识别能够解决一部分程序算法无法覆盖的问题。包括组件识别和代码表达两个主要步骤。可以使用 puppeteer 自动生成组件截图样本，解决样本类别数目不均衡的问题。

可以写一个页面，每刷新一次这个页面就会渲染出不同类型不同样式的组件。组件是随机生成的，在实现组件样式时做了 padding、margin、文字内容文字大小等的随机生成，唯一确定的是要给每个组件加一个类型标记。再用无头浏览器 puppeteer 自动访问这个页面，每访问一次，从这个页面中根据我们设置好的类名获取所有组件节点类型，并截图保存进类别数据集。这种基于有限的规则生成的样本，是只能作为真实样本的少数补充。

模型识别的结果可以用于给类名一个易于理解的名称、或者自动生成字段绑定代码，如果识别到是一个按钮组件，可以生成无障碍属性代码，或者在生成代码时自动引入外部组件，如果识别出是一个模块，可以生成模块化代码等等。从模型精确度和预测耗时两个方面选择合适的模型算法进行样本训练，最终将训练好的模型部署到云服务器上供用户调用去识别 UI 界面中的组件，组件识别结果最后通过DSL函数转换生成代码表达。

生成DSL时可以采用了整分的思路，即将大布局不断的切分成小布局。

而且，对于程序算法和模型算法目前都还不能解决的问题，可以通过人工标记设计稿图层的方式来解决。不断提升整个环节的能力，使得生成代码的具有高质量和高可维护性。

总结

低代码不适合开发面向客户（toC）的应用，在许多公司这部分才是最占人力的。对于企业内部应用，低代码可以显著提升效率，但效率提升带来的不是人员减少，而是需求增多，很多之前中低优的项目终于排上了。同时低代码平台解决不了「根本任务」，图形化编程只适合特定场景，用它来做控制流还不如写代码，因此依然需要研发。