软件正在吞噬世界，但世界上只有0.5% 的人会编写软件。另一方面，超过 20 亿人知道如何使用电子表格。
随着 Zapier 和 Airtable 等成熟无代码平台的出现，运用无代码进行开发的人数在急速上升——这让开发人员十分焦虑。
1979年，VisiCalc 正式面向市场推出。作为 Excel 的前身，VisiCalc 允许非开发人员以点击的方式构建自己的程序。
VisiCalc 在当时并不像预编译的会计软件那么容易使用。早期的评论者指出，这是十分关键的，“因为 VisiCalc 不是预编译的，这使它比同类程序强大、灵活得多。”
换句话来说，这相当于拥有一个较低门槛的无代码平台允许用户解决无数其他用例。
StackOverflow 的年度调查发现，VBA（ Excel 的编程语言）多年来一直是最不受开发者欢迎的语言之一。这些工具在生产环境中通常很难迁移，因为他们缺少通用软件的“版本控制”、“测试”等关键功能。
无代码自诞生以来也常伴随着不少的争议。较为早期时，部分开发人员将整个无代码系统视为无法扩展，服务于业务关键型工作流的原型平台，认为无代码只能构建简单的应用，过于局限从而没有较大的发挥空间。
为什么开发人员会拒绝无代码
无代码，仅看名称是不是就意味着开发人员的工作将被自动化？事实并非如此。
据统计，目前中国会写代码的开发者只有700万，业务管理者会用 Excel 的可以达到2个亿。即使随着开源、API 经济以及更多技术出现，数字化人才缺乏依旧是企业转型的一大痛点。麦肯锡今年的一项调查报告称，87% 的企业已经看到开发人员短缺，或者预计几年后会出现短缺。
抛开对自动化的担忧，缺乏可扩展性才是开发人员对当今无代码平台担忧的关键点。
大多数开发人员认为，很多无代码MVP（ Minimum Viable Product ，凭借其快速测试和试错，帮助许多企业获得产品在市场中的快速反馈，并以此方法循环和快速迭代，以最小的代价去获得产品最大化成效）都具有 “ complexity wall ” 。即当无编码人员将 MVP 交给开发人员以进行进一步增强时，开发人员要么必须编写大量不稳定的中间件，要么完全重新重构新的中台系统。例如：
- Airtable（低代码工具，可以让非技术性的终端用户使用类似电子表格的界面来构建自己的关系型数据库）当用户希望将现有的的数据迁入 Airtable 时，开发人员常被 Airtable 严格的速率所限制，即使从 Airtable 到数据库大规模迁移，也必须替换无代码逻辑 + UI 层。
- Zapier（无代码工具，可以整合两个或以上应用程序，自动执行重复性工作，从而提高效率）。开发人员希望在版本控制和测试中分层，但 Zapier 缺乏对这些基础功能的支持。开发人员必须将 Zapier 中的所有内容重建为 AWS lambda（一项计算服务，无需预置或管理服务器即可运行代码）。
大多数无代码平台中的 “ complexity wall ” 阻碍了无代码的大规模投入使用。
无代码如何变得更具可扩展性
很多企业都承认无代码为公司带来了积极的影响。无代码可以赋能开发人员提升开发效率，将更多时间和精力专注于核心产品，并允许业务人员自主学习搭建符合业务需求的应用系统。
但还是有部分企业拒绝大规模使用无代码，其主要原因可简单概括为：他们认为无代码缺乏可扩展性和可维护性。
可扩展性
可扩展性决定了用户在生产系统添加新功能的难易程度。开发人员如何轻松地将新功能添加到工作流程中？是一定要写中间件吗？还是完全重新平台化？
无代码工具又该如何实现可扩展性呢？
一、通过良好的 API 和 Webhook 提升协同能力
由于无代码数据存储很少能像 SQL 那样被访问，开发人员必须编写大量中间件来从一个存储迁移到另一个存储，并且时常担心担心数据是否同步，在次过程中还会有 API 的速率限制，以及较低的安全性等问题。
意识到这一点后，很多无代码厂商都通过设置良好的 API 和 Webhook 以提升协同能力。
以无代码厂商轻流为例。在轻流，Webhook 位于「流程中」，可以在流程的任意环节向第三方系统伸出「hook」，推送相关事件，拓展了「流程」的便捷，并且可以触达到外部的第三方系统。同样的，轻流还推出了 OpenAPI ，任意的系统，可以在任意时间对轻流做系统数据的调用。API不仅可以用于系统的连接，也可以做系统的存量备份，在轻流提供的安全防护下进一步的对数据进行再次的保障和容灾备份。
二、在需要时提供回退到代码编程的方式
开发人员通常希望能够使用代码来处理工作流中的复杂任务，而无需搭建新的平台。脚本在无代码平台中很常见，但最好的脚本形式常常涉及对多种语言的支持（尤其是用于错误检查的 TypeScript ）、对库（npm模块）的支持和版本控制。
最好的例子是 Pipedream（一个集成和计算平台，借助 Pipedream ，开发人员可以利用 700 多个预构建的集成应用程序并编写任何Node.js、Python、Go 或 Bash 代码，以使用自己的自定义逻辑扩展集成），它提供让用户将各种 API 连接在一起的功能，并且在你需要时进行代码级控制，在你不需要时不需要代码（直接进行简单的 UI 操作）。
在此案例中，Pipedream 用户可以 通过UI界面快速选择一种方式获取到 Google 表格的数据，然后根据需要修改代码。Pipedream 还允许开发人员使用大多数其 npm 软件包，与其他代码沙盒不同，这些代码沙盒通常严重限制可以使用哪些类型的库。Pipedream 还将很快推出对 Python、bash 和 Golang 运行时的支持。
三、良好的开放性
无代码系统一定不能是封闭的系统，它更应该与其他系统做好连接和交互。
伪开源无代码产品无法维护，当厂商进行代码更新后，会产生代码一致性问题，导致代码差异冲突，造成不可逆后果。但无代码产品的接口能力和 API 能力需要重点关注，所以，在无代码产品上实现的二次开发非常类似“插座”和“积木”，把二次开发定义的代码块，同 API 和无代码产品进行交互。
可持续升级
可持续升级，决定了业务关键系统已经投入生产后对其进行迭代修改的难易程度。
现如今，运用无代码构建初期原型是很容易的，但是，一旦投入生产系统后进行迭代是非常脆弱和易碎的。
这是当今无代码被归入简单的工作流的最大原因之一——不是因为不可能构建复杂的工作流，而是因为随着时间的推移，任何非微不足道的复杂性都是无法管理的。
我们需要将更多的概念从 DevOps（一组过程、方法与系统的统称，用于促进开发应用程序 /软件工程、技术运营和质量保障QA部门之间的沟通、协作与整合） 引入无代码，从版本控制和可监控开始。
一、版本控制
较为理想的状态是：一旦无代码工作流成为业务关键型并部署到生产中，用户就能够对其进行版本控制。
因此，开发人员可以将系统的配置（模式、逻辑等）声明为代码，以及使用 git（开源的分布式版本控制系统）进行版本控制，这样就能够扩展到尽可能多的系统——不仅仅是数据结构，还有逻辑，甚至是无编码的UI界面。
二、可监控性
当今的无代码中，逻辑在平台上广泛分布，很多无代码平台都在构建自己的逻辑模块。但当产品出现问题时，开发人员很难了解事情的来龙去脉。如果不知道系统中发生了什么问题，就没办法对其进行改进。
所以很多无代码平台都大力提倡功能的可监控性。例如，SwitchboardSwitchboard（云共享办公空间，通过将团队和工具聚集在一起进行并肩协作，为远程工作提供动力）正在为 Zapier 和 Integromat（RPA厂商，其产品可以帮助用户将十多种日常办公软件的，数据输入、提取、上传、下载等操作流程实现自动化 ）构建错误监控和事件管理平台。此外，无代码平台还为用户提供更多的日志记录， 可以更轻松地与 Datadog 等警报堆栈集成的 API 。
无代码，不仅仅是MVP
无代码给很多企业的初印象，是构建 MVP 的利器。很多公司常常在业务拓展期利用无代码平台自研的套件来构建产品的初期原型，快速核验核心功能，以降低开发成本。但当无代码平台能够赋能开发人员对其产品进行扩展修改时，无代码同样可以用于构建 MMP（ Minimum Marketable Product ）帮助企业缩短开发时间，解决业务痛点。
在无代码产品的应用与实践中，越来越多的无代码厂商已经意识到产品缺乏可扩展性所带来的弊端，并通过多种方式来提升平台的可扩展性，不断拓宽无代码平台能力边界。
数字化浪潮下，企业信息化建设必然需要借助无代码技术提升系统开发效率，加速企业数字化转型。无代码的未来将不可估量。
Leave A Comment?
You must be logged in to post a comment.