低代码会是一地鸡毛？还是会一飞冲天！

近几年，“低代码”这一概念越来越受到追捧，和贬低，越来越受到肯定，和嘲讽。

这两种极端化的评价和冲突在网络上被无限放大，形成了一个很有意思的现象：

骂“低代码”产品的， 都不是使用低代码产品的人。
夸“低代码”产品的， 也很少是真正从低代码产品上获益的人。

这次我们不站队，仅从客观程度分析形成这两种评价的原因。

---

01 首先你得真正理解“什么是低代码”

很多人连低代码是什么都没搞清楚，就在网络上激情开麦，导致的后果就是出现了类似这种问题：

还有很多争议性比较大的问题，比如这种：

当然所有的问题都是值得被讨论的，但不可否认的是，很多人对于低代码的理解还是夹生的。

所以到底什么是低代码？我举个例子：

Photoshop是一个非常著名的图片编辑软件，专业而且复杂。
PS高手可以用这个软件实现非常牛逼的图片编辑操作，追根溯源，其对图片的每一步操作的背后都有着非常复杂的图像处理算法，也会涉及到大量编码。
但使用者不需要写这些复杂的算法和代码，只要根据PS软件内现成的编辑模块进行操作即可。

所以说，如果有合适的工具，即使不写代码，也可以干很多的事情。

---

02 低代码开发VS自研系统？

这是关于低代码争议性比较大的话题之一，也正是由于这个争议，衍生出了“低代码取代程序员”的讨论。

但这根本就不是同一纬度的话题，这就好比你硬要拿一个数字填充的涂鸦画和正正经经的油画去比。

数字填充油画示例

几乎所有的低代码平台发展初期，都是从对标中小微企业开始的，这些企业本身就不需要像大型企业那种非常复杂的业务系统，但他们也有业务上云的数字化需求。

就好像那些不会油画的人，想要画一副油画，也不要有多牛逼高大上的功能，这个时候请专业的油画师成本太高，而低代码产品就充当了数字油画填充的角色。

而对于那些大型企业来说，已经有了成熟而庞大的业务系统，低代码的作用就主要在于帮助企业“跑通数字化的最后一公里”，更多是辅助作用和填补优化作用。

但随着低代码技术的发展，低代码逐渐基于业务发展起来，YonBuilder 和 APICloud 就是低代码领域在企业复杂业务和 ToC 敏捷应用两个方向的极致代表。

那么低代码适合开发什么应用？

1. C 端小程序：利用低码快速开发小程序/H5 页面，并可以快速定制化、个性化。
2. 数据模型应用：针对关系数据库中的数据，基于数据库表单的增删改查应用。
3. 表单应用：基本的数据的收集、处理、上报页面应用。
4. 企业门户：低代码可以帮助快速创建具有公共前端或用户界面的门户阵列，而不是手动编码和后端组件。
5. 业务流程/系统：为任何复杂的任务定义工作流并建立流程，以跨多个部门自动化操作,完成业务流程系统，比如 OA、人力资源管理、财务管理、采购管理等。
6. 基于物联网的应用程序：企业可以使用低代码来构建应用程序和功能，以集成 IoT 终结点并收集数据，通过后端计算基础设施发送 IoT 数据，并向内部或外部客户提供最终的数据请求。

简道云解决方案中心

---

03 机器帮写代码VS组件调用组合？

市场上关于低代码开发程序有两种主要形式，随着行业的发展，一种可能会“一地鸡毛”，另一种则可能会“一飞冲天”。

第一种：开发过程中依然会涉及到代码，只不过代码是由系统自动生成的。

这种低代码开发的方式早在2000年以前就有了，典型的有：Visual Basic， Delphi等可视化开发工具。它们倡导和鼓吹的，其实也就是机器写代码，所见即所得的。

这种开发方式发展到最后很有可能就是“一地鸡毛”。

因为这种后台系统生成代码，出现问题客户还是要翻出后台代码去改。以系统后台自动帮助用户生成代码的方式提供的低代码平台，前途是非常有可能一地鸡毛的。

第二种：平台提供大量丰富的可以定制的功能和组件，用户则聚焦于自己要实现的业务逻辑，利用这些组件进行“创作”，搭建应用。

同样是上面的PS的例子，用户在制图的过程中，并没有使用和接触到背后的代码，使用的是系统提供的非常全面，细致而复杂的各种模块。

这里只涉及到对已经实现很完善的各种组件的调用和组合，并不涉及到代码本身，所以这种平台的低代码应用是可以做到零代码搭建成功的。

这就是APaaS的概念。

不同于SaaS直接提供应用，也不同于PaaS提供平台，APaaS的主要作用是给真正的应用提供各种各样的组件，用户可以在这组件的基础上搭建自己的应用。

而且这种方式搭建应用，和传统的请专业开发者来给自己构建系统的好处是不言而喻的。

市场上并不缺乏开发者，但是对特定应用来说优秀的开发者，同时还需要懂业务，是很宝贵的资源。

很难做到每个企业都可以网罗一批优秀开发者，投入足够的时间进行开发给自己企业使用的系统，无论是时间成本还是钱，代价都是巨大的。

相反的，通过应用平台APaaS的方式，公司可以集中市场上对特定领域的业务流程非常熟悉，有最基础的开发能力的员工，开发出适用于这个行业这个领域这个业务的对应组件。

这种方式的低代码平台，如果做好了，前途自然是一飞冲天。

当然一旦使用组件进行搭建，必然会遇到灵活性的问题。

模块化必然会带来灵活性的牺牲，然而和收益比起来，灵活性的牺牲并非是天大的问题。和模块化带来的各种好处比起来，这点灵活性的牺牲是可以容忍的。

当然前提条件是其能够聚焦特定的应用领域和行业，让对业务非常熟悉的，好的开发人员，打磨出一套适合行业应用开发的，高质量的组件。

以上。