只有足够的开发人员来绕步。企业长期以来，软件开发可以复杂，昂贵，而不是企业内的一切都是关键任务或客户面临。并非所有的申请都需要有防弹或带有一系列功能;有时基本的工作软件足以使团队或部门成为更高的富有成效性并提供更多价值。您可以了解企业如何应对他们无法与诸如打包应用，外包等等事物构建的事实。
最新的“银弹”以低代码平台的形式出现:程序员使用这种环境通过图形用户界面和配置来创建应用软件，而不是传统的计算机编程。典型的低代码平台将提供拖放式开发环境和模型驱动逻辑，使创建者能够构建解决其特定需求的应用程序。
前提很简单：您不需要在有限使用应用程序上浪费您的Dev团队的时间;只需获取某人了解您的企业以在低代码环境中创建所需的应用程序。低代码承诺清除积压，激发创新并建立一个公民的开发者劳动力。
这种方法有很多粉丝，也有很多批评者。例如，分析机构Gartner预测，到2024年，三分之二的应用程序开发将只在低代码平台上完成。这并不意味着传统的软件开发输出会急剧下降，而是意味着更多的新应用程序是在低代码平台上开发的。
为了充分利用任何技术，都有必要挖掘炒作和批评的背后，以正确理解其优缺点，而高度极化的内容可能会让这变得有些困难。一方面，如果使用得当，低代码可能成为组织技术工具包的一个有前途的补充。与此同时，批评人士(通常是软件开发人员)提出的担忧不应该被完全忽视。需要一个平衡的视角来理解低代码是否适合您的组织。
在哪里低代码可以完成工作
在任何典型的企业中，都有大量不需要全栈开发团队的业务增强应用程序，在这些应用程序中，持续部署、最终用户验收测试或测试驱动开发等实践可能会有些过头。想象一下，一家银行想要引入一个简单的、分行内的客户服务触摸屏或一个简单的分行员工移动应用程序。
我们看到，以下应用特征可能会落入低代码的甜蜜点:
- 该应用程序主要是一个简单的UI，您可以在企业中新开发的数字平台或API的顶部利用建筑物
- 没有现成的版本
- 现成的应用程序太复杂或太昂贵了
- 要解决的业务问题简单明了
- 结果系统架构的低代码应用程序适合您的整体IT遗产
- 低代码开发团队可能很小，并且不需要与其他团队协调太大
跑到边缘
对于那些考虑低代码部署的IT领导来说，真正的挑战来自于考虑边缘情况，即我们超出了低代码的最佳点，进入了低代码可能不适合的混乱现实问题。
复杂
复杂性。很少会创建复杂的应用程序，但当今企业的现实是，复杂性是生活的一部分。低代码环境倾向于使用可视化的比喻来描述逻辑程序流，一旦代码的“图表”变得太大，它就变得非常难以理解。因此，逻辑的复杂性有一个上限，可以合理地在低代码平台中实现。
这是许多低代码平台提供商识别的问题。他们的解决方案：如果有的话太复杂了，你可以放下自定义代码。这就是警报响铃应该开始振铃的地方。
任何有过定制COTS包经验的人都知道偏离常规安装太远的危险。如果你开始修改低代码应用程序背后的代码，你能确定你将保持升级路径吗?如果没有，您会后悔没有让您的软件专业人员提前交付定制的解决方案吗?
安全性和测试
不仅仅是迁移路径。安全呢?我们都知道当今企业面临的众多风险，但当您不真正了解应用程序是如何开发的时，您如何理解您的弱点可能在哪里呢?
在原型应用程序开发过程中，您可以实现测试制度以将错误Bash进行错误并检查代码的质量。当您处于低代码环境时，您将依赖于在执行应用程序开发的那些中，以测试其结果以及低代码伙伴提供的工具。在我们遇到的许多实例中，测试低代码应用的工具缺少我们期望的内容。
无论您想要进行什么应用程序开发，都必须验证它是否正常工作。您的整个测试策略需要能够支持在原始用例中建立的风险级别。我们经常会遇到这样的假设:如果您编写的代码更少，就像您编写低代码时所做的那样，那么出错的可能性就更小。但我们认为进行测试是谨慎的。
一体化
很少有企业应用程序是完全独立存在的:大多数企业应用程序需要与其他系统集成，并且能够使用数据并将其公开给这些系统。我们看到越来越多的低代码平台承诺，它们将使您能够构建成功集成所需的api。
如果你的低代码应用只与少数其他系统集成，这可能是可以的。但是，当您必须集成几十个系统时，管理api的复杂性不应该被低估。了解低代码平台会提供什么样的文档可能是值得的。它能让你长期管理你的api吗?
锁定
最近，我们的客户提出了一个比较不寻常的问题:“如果谷歌倒闭了，我们该怎么办?”这种情况发生的可能性似乎微乎其微，但这是许多受监管行业的领导者被迫考虑的一个问题。因为无论任何业务影响事件的可能性有多大，他们都需要有一个答案。对于低代码也是如此。
许多低代码提供程序可以保证，在需要迁移平台的情况下，您可以将应用程序作为生成的代码导出，并从那里重新编译应用程序。这可能是一个好的开始，但是我们敦促运行对操作有重大影响的低代码应用程序的人测试他们成功做到这一点的能力，并检查结果代码是什么样子的。它可能能够运行，但是您能够对它进行更改吗?在这些情况下生成的代码通常在算法上是正确的，但对人类来说是不可读的。它会正确地执行，但却永远不会以一种有意义的方式改变它。这很像灾难恢复的格言:您不希望等到需要时才知道备份计划是否有效。
缩放成功
每个人都喜欢一个成功的故事，但是当谈到低代码时，成功可以带来自己的一系列问题。进入任何企业，您可能会发现开始突出的应用程序的例子，但已经过时地证明了他们的价值并在整个业务中传播。并且鉴于可能性，我们认为使用低代码平台时计划为此有意义。
如果你的一个团队在你的低代码平台上创造了一些引人注目的东西，如果它真的成功了，你会怎么做?您将如何处理集成、风险评估和测试?您将如何处理增加了比原始用例更复杂的特性请求?很容易假设您将能够进行沙箱式低代码开发，并将其与您的其他软件资产区别对待。但现实情况是，当低代码应用变成关键任务时，你需要做好计划。
实践中的低代码
让我们考虑一下在实践中可能会发生什么。例如，假设你想为你的快递服务创建一个包裹跟踪应用程序。该应用程序本身相对简单:在配送链上的每个点，从仓库到投递点，包裹将被扫描，这些信息将通过一个web应用程序呈现给客户。
在使用低代码平台上设置构建此应用程序之前，您可能需要考虑可扩展性。可能，您可以为此应用程序提供数百万用户 - 您是否检查了后端（和低代码平台本身）可以应对这种需求水平？
您可能还需要考虑UI。你可以合理地预计，你的客户正在使用的设备类型将有高度的多样性。低代码平台就是为了支持这一点而设计的，它们的内置UI小部件可以跨设备工作。但是包裹跟踪的UI细节是什么呢?如果你的低代码平台没有时间轴模块，你就会陷入困境。如果时间轴模块的行为与您希望的不完全一样，您可能被迫要么接受它，要么下拉到自定义代码中根据您的喜好调整它。
即使你克服了这些障碍并让你的应用程序成功部署到数百万用户，你仍然面临挑战。随着世界转向网上购物，回报率正在成为零售商更加紧迫的问题。您的交付应用程序是否可以与零售合作伙伴的系统集成，并帮助他们跟踪正在退回哪个软件包？如果它只是一个零售合作伙伴，答案可能很好，但随着越来越多的合作伙伴来船上，集成点的数量升起 - 并且管理复杂性的任务变得令人指导更加困难。
低密码安全区
组织想要使用低代码有很多好的理由，但我们总是建议在一组明确定义的护栏内这样做。如果你的应用程序通常需要两到三个开发人员，而业务逻辑非常有限，应用程序只会与少数其他系统集成，那么你可能处于安全区域。
一旦超越这些边界，您可能仍然希望利用您的低代码平台 - 但您将希望认真考虑潜在的风险和您所在的步骤以减轻它们。
最后，你可能会认为安全区是团队规模的函数。这并不是为了说明问题，但我们确实认为，一旦你有超过六个人在开发一个应用程序——包括那些测试人员和类似人员——这个应用程序可能会变得过于复杂。低代码无疑可以给您带来一些快速的好处，并证明它在企业中的价值。只是要注意不要在平台上做太多事情。
本文于2021年5月更新。我们对原始版本做了一些小的修改，使一些内容更加清晰和更新。同时，我们也直接意识到低代码叙述的两极化，以及客观视角的需求。