用低代码平台开发比用IDEA还牛逼吗？

Z时代
2024-01-10
分类：综合

有没有发现，每隔几年总会有一些火热的前沿词汇出现在我们面前，比如：云原生、微服务、中台、Servless、低代码等等。那么你是否有想过，这些概念的背后是什么推动的呢？结论并不难发现，从各种概念的目标上去合并同类项，它们的本质目标都是：提高研发效率！

在提高研发效率的道路上，各种方案都有着不同的侧重点，有的着力于基础设施的完善，有的着力于系统架构的优化，有的着力于生产工具的更新。拿最近最为热门的低代码平台来说，更多的是站在生产工具这一侧重点之上。

不同于传统IDE的生产工具

说到生产工具的提升，我们往往第一反应想到的是IDE上的优化，比如：IDEA、Eclipse这些开发工具上所做的文章，而低代码平台与这些还有着本质区别。

在传统开发工具的产品迭代上，我们更多看到优化点是：更酷炫的界面、更友好的编码联想、更精准的错误提示、更方便的调试流程、更便捷的构建工具等面向传统开发者的完善方向。这方面的生产工具拥有更高的灵活性，因为我们可以根据团队偏好和管理需要去自由的构建我们的工程风格，来完成我们的开发目标。

而低代码平台的实现目标与传统开发工具产品不同，他们致力于让用户写更少的代码，以更友好的编码方式，降低数字化系统建设的人才门槛，让更多的人可以快速的上手并参与到企业信息化建设中去。那么为什么低代码平台可以降低开发人员的上手门槛，可以加速企业的数字化建设呢？

我觉得主要有以下几个方面：

可视化的编码方式

开发者对领域模型的设计、用户界面的实现、业务流程的规划等核心编码逻辑，都可以用拖拉拽的方式实现。

比如：我们以专注低代码领域多年的奥哲旗下产品云枢为例。假设我们要实现一个企业常规的请假流程，是如何实现的，来体会与传统开发之间的主要差异！

第一步：领域模型设计。传统开发模式之下，我们要做的是根据我们所用的数据库来完成表结构的创建，这里就需要我们维护好相关的创建脚本。而这里我们可以看到，我们只需要通过可视化的方式来完成领域模型的设计，同时并不需要考虑具体用的什么数据库，对于选择不同数据库之间的差异可最后依靠平台来自动完成适配。

第二步：操作界面设计。在所有的低代码平台中，几乎都提供了所见即所得的表单设计能力。其原理就是将各种常用的页面元素实现组件化，并与领域模型实现关联绑定之后，通过配置完成业务数据的输入存储与读取展现。所以，如果业务需求在已有的现成组件都可以满足的情况下，用户在实现的时候，是不需要编写代码就可以完成界面的设计与实现。

第三步：业务流程设计。对于流程化的业务需求，常规模式之下，简单的我们可以用状态模式或一些轻量级的状态机框架来编码实现，复杂或灵活一些的，我们需要引入工作流框架来实现，需要做很多复杂的前置配置并且需要较多的学习才能上手并用好。而通过低代码平台中的流程设计界面可以看到，流程开发配置过程被简化了很多。

从上面的几个产品开发核心步骤中，我们可以发现，低代码平台都在尽可能去封装各种常用编码操作，尽可能的让用户可以所见即所得的去完成各阶段的设计与开发步骤，尽可能的减少代码的编写，对于一些简单需求，甚至实现零代码完成的目标。

开发运维一体化

通过上面可视化的编码，我们是可以快速的完成一个业务需求的开发了。但开发过程对于一个需求的实现，只是前期过程，那么后续的项目打包、版本管理、产品上线又是怎么样的呢？

对于一个成熟的低代码平台来说，这些内容必须涵盖其中！这也是与传统开发模式存在较大差异的部门。但这里由于低代码平台的定位不同，可能会有几种不同的处理方案，常见的主要有两类：

第一类：SaaS化的部署能力。这种低代码平台往往提供较为轻量级的实现能力，比如：在线化的Excel工具。用于实现一些简单的问卷调查、数据采集与统计等功能。这类需求不需要太复杂的界面交互、流程控制或数据处理的情况。比如：奥哲旗下的另一个产品：有格

这一类产品，由于定位于轻量级低代码平台，所以他的应用范围会更偏向于一些常见的模型，所以平台也会提高一些模版，便于用户快速上手，基于行业固有模版去做二次定制来快速实现符合自己团队需要的一套应用。

而整个开发过程也相较上面提到的云枢也更为简单，比如：下面是用该工具完成的一个敏捷研发管理应用。

由于这类平台所面向的应用场景较为简单，往往它们具有临时性、周期短等特点，它们并不需要部署到特定的环境，自然也没有与私有资源的对接，所以这类平台往往直接就可以在平台侧实现对用户应用的部署与使用。

第二类：提供DevOps与私有化资源的整合能力。相较于上面的轻量级低代码平台来说，这种就是比较重量级的了。在可视化的编码方式一节中，我们所举的云枢]就是这样一个兼备了运维能力整合的低代码平台。

它涵盖了从产品版本的构建构建：

到基础设施的维护：

再到产品的发布：

涵盖了一个需求从开发到上线的完整流程。所以，我们可以看到对于一个业务需求的时候，通过低代码平台的应用，整个产品研发过程，都被整合到了一个平台之中。这与我们应用传统生产工具有着非常大的差异，我们不需要再去自己设计代码库的版本管理、构建包的管理、部署资源的管理等一系列的架构管理设计。通过这类低代码平台提供的整体管理方案就能支持产品的开发、测试、上线全流程管理。

虽然强大，但也不是银弹

在看了上面介绍的第二类低代码平台，是不是感觉这东西非常强大，那么它会是开发效率提升的银弹吗？未来会像有些厂商说的：未来人人都是开发者，程序员都要失业了？

对于宣传“未来人人都是开发者”这样的观点，我是不认同的。因为我还是相信软件开发不存在银弹！虽然低代码平台看上去已经很强大，但不论是轻量级、还是重量级的低代码平台来看，也都是针对一些特殊客户群体的。并不存在一款低代码平台能够适应所有的开发团队与业务场景，所以低代码平台也不能被笼统称作为提升效率的银弹，应该说在更符合个性化需求的前提下，来帮助开发团队或者企业提升效率。

对于轻量级的低代码平台而言，因为功能相对简单，对于复杂多变、需要更多创新元素的互联网C端产品来说，就不太适合使用。我认为这一类平台更适合应用于一些业务逻辑更为稳定的场景，或一些临时性的数据采集、统计类需求，就像奥哲有格中的那些模版应用，这些经过行业长期沉淀，大部分团队都类似，最多有一些小变化的应用方向。或者一些类似问卷等临时性的需求，就特别适合使用。选择一些产品易用性好的平台，甚至都不需要开发介入，一些聪明的产品和运营都能自己通过配置实现一些简单需求。

对于重量级的低代码平台而言，因为功能更为专业，可以满足比轻量级平台更为复杂的业务需求，并能适配更多不同团队的管理模式。但这类平台使用中涉及的概念还是非常众多的。所以，只能说这类平台对于开发人员来说会更容易上手。对于没有开发思维的纯业务人员来说，还是具备一定的门槛。这类平台更适合应用于大型开发团队对大企业内部系统的开发，对于人员配置上，相较传统开发要求更低，但对于开发速度表现更快。

但目前这类平台对于一些复杂场景，尤其对于一些高并发的业务场景还有提升空间。因为在这些场景中，我们往往需要动用很多中间件、缓存、限流、熔断等技巧来保障系统的良好运行。因此，虽然我认为低代码平台是一个很好的工具，不论轻量级的还是重量级的，都能解决部分场景的开发效率问题。但如果想让业务开发人员专注于业务功能实现，并覆盖所有场景，那么在性能架构方面要做出强化。

总的来说，我建议我们在选型与应用低代码平台时，一定要充分理解自身业务场景的特点与各低代码平台优势之间的关系，必须有的放矢，才能让低代码平台发挥最大的价值！切勿拿了平台看到需求就到处推，不要因为好工具用错场景，被喷的一无是处！

最后，做个小调研：你们开始使用低代码平台了吗？你觉得低代码平台给你们带来了效率的提升吗？加入我们的技术交流群，聊聊你的观点！