共计 2398 个字符，预计需要花费 6 分钟才能阅读完成。
低代码（零代码）软件平台、套件、工具和相干服务正在疾速地宽泛遍及和扩大。当初许多人都晓得，低代码软件解决方案提供的加速器和自动化，能够减速软件应用程序开发人员的工作……这就意味着（在这个开发人员匮乏的星球上) 低代码很受欢迎。
低代码通常是将与软件编码相干的更容易定义和可反复的工作组件化，它并不适宜小白，依然须要通过专业培训的软件工程师来操作（一些业务人员能够应用更高度形象的零代码服务)，但低代码已被宽泛认为是咱们当初创立应用程序的重要形式之一。
当初每个供应商都是低代码者
已经低代码是业余的低代码平台组织独占的业余畛域（正如咱们之前所说的，通常包含 Appian、Mendix 和 OutSystems），当初低代码曾经渗透到整个企业软件供应商畛域的打算中，有好几家公司可能只是为了取得一些“话语权”而将其退出进来。
低代码 / 无代码并不陈腐，十多年来它始终是精打细算的企业和缺乏经验的编程人员的抉择。但当初的低代码 / 无代码平台比以前更弱小，在技术环境中长大的年轻一代领有更宽泛的技能根底来操作低代码 / 无代码平台。
目前市场上有许多低代码平台，那么想应用低代码的企业应该如何与这些提供这种新型企业应用程序工具的公司进行交换呢？
因为低代码提供的范畴不同，抉择平台这个问题是很辣手的。大多数企业软件都是为一个特定的性能而构建的，比方 HR、工资单、洽购等等。而对于低代码是没有这种限度的，你能够在任何我的项目上应用它。
低代码—非凡的工具
在购买低代码产品时须要思考的事件有很多，这意味着理解怎么与在这个 IT 市场畛域经营的供应商进行沟通是十分重要的。
所有这些低代码的开发工具都是不同的。有一个很好的类比: 把所有可用的低代码工具纳入一个类别，就像把旱冰鞋、滑板、轮椅、自行车和汽车纳入一个被称为“轮式交通工具”的大类别。它们都能够把你从 a 点带到 b 点，然而用户体验差异很大。
对于低代码工具来说也是如此; 各个工具集都有不同的个性、接口、限度和用例。想要采纳这些工具的企业须要理解的是，只有明确洽购指标，能力找到对应的工具。
第一个要思考的关键问题是 最终交付的应用程序的可定制水平如何 ？ 实践上咱们认为低代码环境对于应用这些工具生产的软件应用程序具的定制选项无限，但在实践中很少呈现这种状况。企业须要思考客户将如何定制他们的应用程序。
当低代码用户思考如何定制生成的应用程序时，首先，即便用户可能很少须要编辑代码，然而也须要一个能够在代码级别进行编辑的图形化编辑器。其次，还应该确定是否能够增加本人的定制业务逻辑、规定或流程，这个性能将决定软件是否适应你的业务。
如果咱们不必了会怎么样
软件洽购主管、零碎架构师或软件开发人员很少会想到一些负面影响，例如如果他们停止使用既定的平台、开发环境、套件或工具集会产生什么。但在低代码环境中，这是一个重要的思考因素，因为应用低代码供应商的工具可能会导致肯定水平的锁定。
企业首先要留神数据存储的地位，个别会有两种抉择：一种是客户将数据本地存储在本人的总部; 另一种是低代码供应商存储数据并将其作为内部云服务提供。显然，第一种抉择会让数据的导出和下载更加不便，而第二种抉择会让客户意识到他们无奈真正的管制本人的数据。
低代码用户还应该确定他们的低代码应用程序的失常运行是否须要定期订购。如果开发的应用程序须要定期订购能力应用，用户就要与该供应商绑定在一起。为了防止这一点，企业应该寻找不依赖于开发工具运行的平台。这样的话不论是否订购，在这些平台上开发的应用程序都能失常工作。
还有另一个思考因素是用户是否在低代码工具之外保护应用程序，如降级、扩大、修补等。一部分低代码平台生成的应用程序能够在平台内部保护，另一部分低代码供应商要求客户应用他们的平台进行保护。用户还应询问低代码平台实际上生成了什么样的代码。用户须要晓得该平台是生成特定于低代码平台自身应用的专有代码，还是生成更规范的软件编程语言，如 Java、PHP、.Net 等。显然，低代码平台专有的特定代码是很难在平台之外保护的。
开发范畴
因为低代码软件的实质与传统软件工具的实质大不相同，客户还应该思考低代码平台是否满足他们的开发范畴。
传统软件是封闭式的。软件有固定的性能，用户晓得应用它能够开发出什么程序。而低代码软件是不同的。它联合了软件的封闭性和软件开发的开放性，用户能够开发任何平台容许的程序。这可能会导致企业的需要超出工具自身能够开发的范畴。因而，低代码平台背地的供应商比传统软件供应商更为重要。
多年来在一系列低代码工具中工作的教训通知咱们，用户应该听取每天都在应用低代码工具的产品专家提出的倡议。因而着手寻找一个产品专家比减少根底的客服更加重要，因为这些产品专家能够染指帮忙客户更好的应用工具解决问题，例如满足缓和的排期，或攻克开发瓶颈问题。
另一个要思考的问题是低代码供应商对用户的新性能的反对水平，客户须要思考如果他们想定制或集成一个新的个性到软件中会产生什么。任何开发过软件的人都晓得问题总是呈现在像集成这样的小细节里，那么供应商是否反对增加新性能或者帮助集成呢？
引入第三方性能
还有一个须要探讨的问题是，低代码供应商的工具是否能连贯宽泛的第三方 API、框架和云服务？
随着企业将更多的业务转移到云端，不同局部之间的数据传递变得至关重要。除此之外，很多凋谢的框架和服务能够改良低代码的应用程序。用户应该理解低代码平台是否与云服务和框架连贯，比方一个平台是否应用 REST api；还应该理解是否在他们的应用程序中增加诸如“单点登录”之类的服务。用户应该确定集成这些性能的难易水平，以及如果须要进行集成，厂商是否会提供相干帮忙。
起源、范畴和简略性
低代码正在一直倒退，基于前文的一些观点，局部目前正在应用这些工具的用户可能还不能齐全了解它。
对于现在的低代码畛域而言，在最后的接洽过程中提出前文的观点，无疑是对起源、范畴和简略性达到更深层了解的路径。