超越低代码 / 只是低代码还不够

低代码”这个词是这两年来最热的，同时，低代码类平台也如雨后春笋大量出现。那么，我们理解“低代码”这个词的真正含义吗？低代码平台只是实现低代码快速构建应用系统吗？

▶ 对“低代码分类”的批判性审视

    现在的人类经历了几乎前所未有的事件。新冠病毒对世界各地人们的健康，以及政府、行业和企业进行了考验，它还加速了数字化转型过程，并揭示了在这些变化中生存所必需的一些特征，这些特征在未来必须加以考虑。

    所有部门都需要快速采用真正的、深刻的数字化转型。突然之间，医学不得不使用远程医疗，教育必须远程提供，购物明显转向在线渠道，非接触式支付蓬勃发展，隐形语音接口越来越频繁地使用，各种传统的物理事物变得虚拟化和远程化。因此，无数行业加速了已经发生的数字化转型。我们都知道这会发生，但在新冠病毒之前，它以非常缓慢的速度发展。

软件行业现在面临着特殊的挑战和机遇，需要支持和赋能成功的行业，并为落后的行业提供解决方案和替代方案。特别是，有一类相对较新的平台和工具能够快速为公司带来重大变革：它们被称为“低代码平台”，GeneXus 就在这一类别/领域中展开竞争。

“低代码”平台已成为传统软件开发的替代品，这是一套工具，允许使用各种编辑器、通用语言、图形和某种类型的代码生成来创建系统，作为寻求更好、更有效、更高效的软件开发方式。

 

▶ 关于低代码的争论

    虽然在这种情况下 GeneXus 属于这个类别（属于某种分类总是好的），但我认为名称中的一些概念以及类别本身的含义是我不同意的，这导致我写本文并参与讨论。

    关于“Low-Code”（“需要更少的编码”）的含义，我认为应该指出它的目标是：

a）比使用传统方法更快地构建业务软件系统

b）由具有不同技术专长水平的人组成的团队来构建它们

这是我完全同意的一个深远而雄心勃勃的目标。但是，有些方面我不同意那些经常谈论“低代码”的人，我想详细说明这些问题：

1）它的名字

“低代码”这个名称专注于一个不一定有好处的特性：编写少量或大量代码本身并不意味着任何好或坏。项目需要很少的代码这一事实并不一定意味着它在完成后易于维护、理解或扩展。术语“低代码”强调了使用这些平台构建系统的方式，并忽略了最重要的事情：使用这种类型的解决方案创建软件的好处。

是否编写少量代码并不重要，重要的是我是否在规定的时间内达成了目标：

• 我可以在 1 周内构建 3 个应用程序来解决实际问题吗？

• 我可以扩展这些应用程序，还是它们是严格的或有限的？

• 我可以在几天内创建和互连系统吗？

• 如果现实发生变化，我可以快速更新开发的系统吗？

• 如果我不得不离开特定的提供商，我可以轻松地转换技术吗？
  

我们确实知道的一件事是，今天的现实比以往任何时候都发生了更大的变化，并且它将继续以越来越快的速度变化，甚至可能比技术本身变化得更快。因此，关注如何快速构建新应用很重要，但更重要的是关注我们如何在工作时随着世界的变化而迅速适应和进化所构建的应用系统。

编写少量代码不是我们的目标，我们的目标是构建一个工具，通过这个工具使各个行业能够受益于我们的平台和专业知识，实现有效的转型。

只要没有其他类别，我们就会继续谈论“低代码”甚至“Multi-Experience/多体验”，但事实是，我会更喜欢其他类别，例如高性能平台，进化开发平台，或者知识驱动的平台。

 

2) 图形化语言

另一件让我感兴趣的事情是，图形语言似乎是这一类别中的一个基本要素。

的确，很多时候一张图片值一千字，但更重要的是，详细而持久的知识是写在字和公式上的。认为图形语言本身将允许系统的业务知识的演化和存储是幼稚和过于乐观的，并不是说完全错误。现有的现实、状况、需求和人以及各种形式的知识不能以这种方式简化或减少。

确实，图形语言通常可以轻松地使工具更具吸引力。图形界面确实可以降低执行某些类型的更标准解决方案所需的知识水平，但在创建、理解和保存知识方面，它是否是最佳选择尚不清楚。双方都有研究和分析，当然今天还没有达成共识：即完全图形化的东西是理想的路径，特别是对于创建随时间演变的复杂系统。

我们只知道，如果某件事不会随着时间的推移而持续下去，那肯定是代码。无论是很少的代码还是大量的代码，它都会消失，它会改变，我们坚信知识不能存储在代码行或图形中。知识必须保存在某种抽象的知识库中，既灵活又独立于技术，以促进要生成的软件解决方案的演进。

 

▶ 低代码的好处

尽管如此，我确实认为“低代码”类别正在帮助我们实现软件行业的需求。

为什么需要低代码类别？

因为在这个充满各种不确定性的世界中，我们必须朝着构建软件的新方式发展。以下是我为什么需要此类别的原因（无论其名称如何）

1) 时间

当今企业构建解决方案所需的时间，无论其属于哪个行业，都无法通过传统的软件开发方法来满足。

2) 资源

为系统构建多体验意味着涉及无数的专家，这通常由于成本原因是不可能的。培训复杂系统需要考虑的所有新技术所需的时间非常长。

3) 未来

从手动编写的代码发展起来非常耗时且成本高昂，而且通常公司难以负担。最有可能的是，今天构建系统的人不会是将来维护它的人。我真的可以把我公司系统的知识用代码写出来，几年后没人会理解吗？

4)复杂性

因为创建一个系统几乎总是意味着创建一个复杂的信息系统，其中涉及对各种技术的集成和理解。即使有高性能专家在场，任务自动化的缺乏也会导致无数代价高昂的错误。

    正如理查德·费曼 (Richard Feynman) 所说，“知道某事的名称与知道某事之间有很大的不同。”我知道低代码类别的名称不是最好的。我认为，即使有些人认为这个名字的含义也不是最好的，但这一类别给市场带来的本质上也是我们期待已久的。我们可能对这个新类别有共识和分歧，但最重要的是它存在并且越来越强大。