低代码：对开发人员可行吗

低代码平台通常因其易用性和业务用户的理解性而受到称赞；但是，一些开发人员可能对这种前景不太感兴趣。如果有遵循编码原则的低代码替代方案怎么办？这样的界面对开发者来说会不会感觉更自然？在问这个问题之前，我们必须问，低代码是开发人员可行的解决方案吗？

在这篇文章中，我们将探讨低代码对于开发人员来说是否是一个可行的选择，以及低代码平台可以为开发人员做什么。 

开发人员的低代码
我们看到一篇 文章说 IDC（国际数据公司）的一项调查指出，68% 的开发人员认为低代码平台 可以用于开发关键应用程序。他们还指出，79% 的开发人员认为低代码平台可以提高工作满意度，其中 80% 的开发人员认为这些平台有助于自动执行重复性任务并节省时间。

数字说明了一件事，但实际使用低代码又如何呢？我有幸在许多企业环境中担任开发人员。其中一些组织使用传统的编码实践和工具；其他人使用低代码工具。这是我的意见：这取决于您的需求和环境。所有低代码平台都有其优点和缺点。确保在提交之前对该工具进行适当的研究。在决定将其作为您的平台之前，看看您是否可以使用它一段时间。也就是说，我可以建议使用低代码工具来增强您的开发。考虑到软件开发 有多忙至少在我看来，低代码工具可用于自动执行重复性任务，这似乎是一种无需动脑筋的选择。例如，导入文件。您可以编写代码每次都导入该文件（很可能您将不得不像我一样在您的职业生涯中导入很多文件），或者您可以使用低代码工具快速构建一个流程，将该文件导入到你的数据库。

集成变得越来越复杂。随着组织的发展，业务需求也在不断发展。您当然可以使用 C#、Python 或 JavaScript 编写代码，但您是否愿意花费大量时间和精力来确保您的代码具有可扩展性、可维护性和足够的灵活性以适应不断变化的用户需求？ 

低代码能为我做什么？
这真的取决于工具。您必须首先问“我的要求是什么”和“我需要工具做什么，不应该做什么？”这样的问题。低代码平台可以自动化几乎无限数量的流程和工作，但重要的是真正了解您对该工具的要求和期望。这和传统的编码一样，你可能不会用C#来编写一个自制的单片机，​​而且用汇编读取文件肯定是不可取的。每项工作都有一个工具。

让我们看一些常见的示例，其中像 Linx 这样的后端低代码工具大放异彩：

构建和使用 API

创建 ETL

文件处理（读、写、归档）

自动化手动业务流程

创建邮件系统

系统集成

这个列表看起来很普通，所以让我们看一个例子：用户要求您读取文件并通过 REST API 使数据可供他们的团队使用。我们有一个帖子在那里我们做到了，老实说，从安装 Linx 到能够调用 REST 服务，我花了不到一个小时的时间。

重要的是要注意低代码还有许多其他地方可以大放异彩。前端低代码工具也可以极大地帮助创建美观的用户界面；同样，这完全取决于您的用例。

资源限制
时间有限就不用多说了。每个开发人员一天只有一定的生产时间。除此之外，我们还可以查看数量有限的可用开发人才。许多组织发现自己处于这样一种情况，即寻找合适的开发人员来满足不断增长的需求正成为一项挑战。 

低代码平台可以帮助解决这两个问题。通过减少花在平凡任务或要求上的时间，我们可以将更多时间和精力花在困难和具有挑战性的任务上。其中一项任务可以很简单，例如导入大量自定义文件或创建自动化流程来执行此操作。我实际上写了一篇关于如何使用低代码工具完成此操作的博客文章，我能够在几分钟内完成。如果我们采用诸如使用低代码工具自动化后端流程之类的方法，我们将能够节省大量的时间和精力。 

权衡选项
在选择低代码工具之前，必须考虑以下几点：

低代码平台必须集成的现有架构是什么？

有什么要求？ 

低代码平台需要适应哪些未来要求或限制？

很多时候，低代码工具的包装不好，因为人们认为它们不能完全按预期满足需求。但是我们需要在这里提出一个问题：是否可能为这个问题选择了错误的工具？我们肯定不会用画笔刷大地板吧？这可能是可能的，但这并不意味着我们应该这样做。 

随着低代码的兴起，出现了许多新工具。如果可以，请查看是否可以获得一个版本来测试它并确保它能够解决您的问题以及它是否适用于您的环境。 

判决
从开发人员的角度来看，低代码会令人生畏、受限，甚至不自然。我们不能责怪他们；许多低代码平台被标榜为“开发人员的终端”。