🎉 我们正在招聘远程 全栈开发工程师测试工程师技术培训与文档专家,欢迎加入

使用无代码/低代码平台进行开发的 5 大挑战

探讨使用无代码/低代码平台开发面临的五大挑战:项目复杂度评估、定制化难题、平台依赖、学习曲线和安全问题。了解 NocoBase 如何通过微内核架构、插件化、开源代码、所见即所得的页面配置和模型驱动设计应对这些挑战。

Deng lijia|

近年来,越来越多的开发者会选择使用无代码/低代码平台进行业务系统的开发。原因很简单:不用从零开始研发一整套系统,并且有易用的模版和可视化的操作界面,大大减少了业务开发的难度和所需时间。

然而,真正尝试过的开发者会发现,无代码/低代码确实能让开发变“简单”,但新的挑战也随之而来。

在这篇文章中,我们将与大家探讨这些已有的挑战,并且可以怎样更好地应对。

4bf9d0eabeb989779d6249d224565e7d.jpg

挑战 1 :难以准确评估项目复杂度和无代码/低代码平台的灵活性

开发者在推进系统研发前会做技术可行性分析,平台选择也是一样的道理。

低代码/无代码平台为了简化开发流程通常会提供一些抽象层(如:高级组件、模块或工具)。抽象层会隐藏底层的复杂性,这可能导致在需要对底层进行更细致控制的情况下,开发者无法直接操作底层代码。

举个最简单的例子:开发者想实现一个定制化的库存调整界面,其中包括特定字段的显示、隐藏或排列等。但由于平台提供了一些通用的界面定制选项,使得开发者无法自由地设计符合他们特定需求的库存调整界面。

所以开发者在选择平台时需要先准确评估自身项目的复杂度,同时判断目标平台的灵活性是否能满足业务需求。(如何才能做到准确评估?之后我们可以单独写一篇文章分享。)

挑战 2:大量定制导致项目后期难度陡增

无代码/低代码平台由于自身特点使然,不可能做到不定制开发就完全满足业务需求。特别是在一些庞大、复杂且深入行业的场景下,定制更是一种刚需。如果前期评估不佳,导致选择的平台本身与项目不是特别匹配,到后期就需要额外增加许多定制开发才能满足复杂的业务需求。

而到此时,业务通常已经进入中后期,无论是继续投入大量定制或者选择迁移整个项目,对企业来说都是一笔不小的成本。

所以前期选择时要重点考量目标无代码/低代码平台可拓展性以及对定制开发的接受程度,避免产生沉没成本。

挑战 3:项目依赖无代码/低代码平台提供商

选择某一平台后,项目难以避免依赖平台提供商。这时便需要多维度的考量平台提供商的能力,包括但不限于:可用性和稳定性、服务级别协议(SLA)、数据隐私安全、平台兼容性等。

其中平台的兼容性代表与新旧业务系统的对接难度(特别是难以预计的新项目)。需要平台有尽可能大的兼容度,能对接不同数据源或不同业务平台。

挑战 4:学习曲线

你可能会觉得,无代码/低代码平台不就是主打简单吗?为什么还会有学习曲线的问题?但对于一些开发者而言,不同的平台有不同的概念、工具和工作流程。

此外,对于经验丰富的开发者来说,需要适应的则是平台的限制和抽象。优秀的抽象层可以提高开发效率,降低学习曲线,并减少开发过程中的错误;而糟糕的抽象层则会带来限制,同时也会使得问题追踪和调试变得困难。

所以选择更符合开发者逻辑的平台显得尤为重要。

挑战 5:安全性问题

通过无代码开发自动生成的代码可能容易受到安全威胁。由于无法直接操作底层代码,开发者也难以实施一些复杂的安全策略。

如果是闭源软件,对代码的可控程度也会降低。同时系统的部署形式不同,也会面对不一样的安全风险。独立部署通常安全性会更强,但是随之而来的管理和维护工作也需要开发者投入时间。

除此外,还需要考虑的安全性问题还包括:身份验证和授权问题、数据加密和传输安全问题以及平台自身漏洞等问题。

平台提供好用的工具,同时需要开发者能力加持

最后我们总结一下。要想使用好无代码/低代码开发平台,一定要提前知晓这些挑战,尽量降低项目风险。开发者的能力在这里起到了更为主导的作用,无代码/低代码开发平台为做工具,目的是提供更便捷的业务实现方式。

NocoBase 作为一个面向开发者使用的无代码开发平台,我们期望提供一个更强大且易用的工具。为了尽可能避免无代码/低代码开发平台的短板,我们在产品设计之初就确定了产品的架构形式:

1.微内核

2.功能插件化

3.开放源代码

4.页面配置所见即所得

5.模型驱动,界面与数据分离

这样的设计让 NocoBase 既拥有了无代码开发的易用性,同时也有定制功能拓展的灵活性。业务构建可以从数据关系入手,再进一步搭建上面的应用层,这样的逻辑也更符合开发者的工作习惯。同时拥抱开源也让我们的产品更健康,来自世界各地的开发者可以轻易地与我们沟通、反馈甚至加入开发。

相关阅读: