低代码，要怎么低？和低代码有关的十大问题( 二 ) 或许是因为Mendix和Outsystems的收

文章插图
还有著名的 SaaS 软件 Salesforce ，十几年前就可以扩展字段来扩展功能，可以看到界面还是 web 1.0 时代的风格：
文章插图
Salesforce
另外还有很多商业产品，它们几乎都有十年以上的历史，最近才改叫低代码平台。
低代码究竟能解决什么问题？对于这个问题，有两种极端，专业开发者会认为低代码平台是个玩具，没什么用，而小白又以为有了这个完全不懂写代码也能开发应用，但这两种想法都不太正确。
要回答这个问题，首先按《人月神话》里的说法将软件开发进行分类：
所有软件活动包括：
根本任务--打造构成抽象软件实体的复杂概念结构。
次要任务--使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
这个分类最早出现在 1986 年作者的论文里，年代久远可能看过的人不多，这里多说两句，「根本任务」指什么？举个例子，比如要实现一款发工资的软件，里面涉及到如何计算所得税，那就得实现个人所得税的计算方法，用什么语言实现这个算法属于「次要任务」，而这个算法本身属于「根本任务」，无论用什么方式实现，你都不可能降低这个算法复杂度，比如个人所得税有 7 个层级，那就一定在某个地方有 7 个 if 语句。
「根本任务」无法解决，因为它就是需求本身，唯一解决办法是砍需求。
低代码平台主要解决的是「次要任务」，用更简化的方式来实现同样的功能，比如前面那个问题，在低代码平台中常见有这几种做法：

提供一种简化的 DSL ，类似 Excel 里的公式。
提供图形化代码编辑器，类似 Unreal Engine 里的「蓝图」，或者类似 Blockly/Scratch 那种拼图的方式。
支持写代码或外部 api 来扩展。
平台内置实现，比如前面提到的个人所得税，平台可以内置一个专门算这个的函数。

其中 DSL 的方式只适合简单场景，因为 DSL 一般不具备复杂的逻辑控制、定义函数等功能， DSL 中要加入这些功能还不如直接用成熟的语言，比如 JavaScript/Lua 。
很多低代码平台使用的是第 2 种方式，这种方式看起来最符合低代码平台的定义，也看起来最高大上，以 UE4 里的蓝图为例，这是我见过最复杂的可视化代码编辑器，可以用它来编写着色器和控制游戏流程：

文章插图
根据 Epic 国内社区经理的说法，蓝图在实际开发中用得更多，我的个人体会是这种编辑器有以下几个好处：

方便预览，尤其是写着色器时可以马上看到每个节点的输出，这点比代码有明显优势。
解决了编程环境问题，不需要花时间配置环境。
节点会列出参数和属性，这样就不需要像写代码那样查手册了，直接点选就可以修改。
调试能实时生效，比如拖动某个数值马上能看效果。
不容易犯错，比如需要符合类型才能连线，因为整个环境是可控的，在很多细节上可以比代码报错跟友好。
最重要的是：蓝图比 C++ 简单得多，也不像 C++ 那样需要多年经验，因此对人员的要求更低，更容易招到人。

图形化编程在三维设计领域取得了不少成绩，比如 Blender、Grasshopper、Houdini、NUKE、Substance Designer 等，通过节点编程的方式极大提升了灵活度，但这些都是针对特定领域优化，并不是通用编程方式。
对于通用编程领域使用节点编辑器是否可行？《人月神话》里也提到过图形化编程，原文是这样说的：
流程图是一种非常差劲的软件结构表达方式。实际上，它最好被视为是 Burks, von Neumann 和 Gold stine 试图为他们说设计的计算机提供一种当时迫切需要的高级控制语言。如今的流程图已经变得复杂了，一张图有若干页，有很多连接点，这种表现形式实在令人同情。流程图已经被证明是完全不必要的设计工具--程序员是在开发之后，而不是之前绘制描述程序的流程图。
更加基本的是，如我们上面所讨论的，软件非常难以可视化。即使用图形表达出了流程图、变量范围嵌套情况、变量交叉引用、数据量和层次化数据结构等等，也只是表达了某个方面，就像盲人摸象一样。