今天我们来聊聊低代码平台中的纯代码，理一理这对欢喜冤家的恩怨情仇。

一般的低代码平台，总爱宣传自己开发过程需要编码的地方是多么多么少，甚至已经消灭了所有代码。久而久之，不免给人一种感觉，如果低代码平台上还有代码的存在，就会显得很失败。低代码是新欢，纯代码是旧爱，有了新欢，抛弃旧爱，这样可不好。

其实，把低代码平台上的纯编码开发模式视为洪水猛兽，大可不必。编码有编码的优势，毕竟可视化不是低代码的目的，高效率才是。如果高低代码的结合使用可以提升开发效率，哪怕是只能在特定条件下提升效率，那都可以纳入低代码平台的能力范围。

为啥还要编码？

最开始，我们思考一个问题，既然可视化开发是低代码平台的特色和卖点，那为啥低代码平台还要提供纯编码入口呢？

你还记得【第 3 讲】中我描绘的天花板级别的低代码平台吗？其中一条标准和低代码平台的用户有关。天花板级别的低代码平台需要能支持各种技能水平的人同时使用。

也就是说，高技能水平的开发者也是低代码平台的目标用户。在这部分用户专业领域范围内的内容，他们更想要采用直接编码的开发模式。除开对这个人群来说，直接编码与可视化开发模式相比的效率因素，一个可能的原因是他们需要有职业获得感，以及出自人性深处的那种“不羁放纵爱自由”的叛逆心理。

我们前面说过，可视化模式凝聚了各路专家的经验，这个经验约束了你必须先这样做，然后再那样做，才能获得更好的效率和更优质的 App。从另一个角度看，就是强制规定了我们开发的套路，你只能这么做。这对于领域小白来说，当然是很舒服的，只要照做就能得到最优解。但高技能水平者往往有自己的见解，期望按照自己的思路来实现，给他们一个代码编辑功能，让他们自由发挥是更好的解决方法。

当然，不见得所有的低代码平台都要做到天花板上去，那发展中，甚至是刚起步的低代码平台，是否就没有纯编码开发的要求了呢？

当然不是。如果说天花板低代码平台的编码模式是锦上添花，为满足一部分人的需要而开放的能力，但对发展中的低代码平台来说，则是刚需，某些时候甚至是雪中送炭。发展中的低代码平台由于可视化开发能力不完善，难免出现搞不定的情况，这种情况往往就需要纯编码模式来兜底。

即使在低代码平台成熟之后，使用纯代码作为一种兜底策略，依然是一种非常好的选择。因为任何事情都逃脱不了二八原则，低代码的可视化模式再好，也只能适用于 80% 的场景。剩余的那 20% 边边角角的场景，如果硬上可视化模式，反而可能吃力不讨好，所以我们把那剩下的 20% 的场景留给纯代码来兜底，是一种很明智的选择。

因此，无论是在发展中的低代码平台还是已经比较成熟的低代码平台，可视化模式和纯代码模式的混合开发，都是有很明确的需要的。

说到采用纯代码方式来实现兜底策略，我在这里自爆一点我们低代码平台 Awade 的黑料。我在【第 7 讲】中介绍了 Awade 的结构化代码生成法，它有一个很重要特点，就是可以生成和人类手写的代码相似的、人能读得懂的代码。多数低代码平台并不会考虑生成对人类友好的代码，为啥 Awade 要这么做呢？

这是因为在 MVP 的初期，我们内部对 Awade 提供的可视化模式的端到端交付能力还心存疑虑，我们也不确定它能不能搞得定。于是心想如果人能读得懂、改得了 Awade 生成的代码，那万一开发哪个 App 时 Awade 搞不定，起码我们还能把代码导出来，手工继续完成剩余部分，不至于烂尾。

后来的事实证明我们的担心完全是多余的，Awade 提供的可视化模式可以很好地应对各种 App 的开发需要。即使如此，它能生成对人友好的代码的特性，并没有浪费，这个特性让 Awade 可以实现高低代码模式的无缝切换，这一点我们等会儿还会再说。

高低代码如何混合开发？

要注意，在我自爆的黑料中，我们原本打算使用的可视化模式搞不定时就人工接着搞的方式，实际上也是一种高低代码结合的方式（高代码指的也就是纯代码）。只不过，这是一种很无奈的、很被动的混合方式，甚至可以说是一块遮羞布。

那么，低代码平台如何优雅地实现高低代码混合开发呢？

在前面几讲中，我已经多次提到，低代码平台的开发过程是有代码参与的，代码是低代码平台的副产品，所以在低代码平台上能否实现高低代码混合开发，从来就不是一个问题。真正的问题在于要不要开放纯代码接口，这一点我们前面已经给出结论了。另一个问题是如何实现混合开发，这正是我们现在要讨论的问题。

形形色色的表达式是高低代码混合最常见的一种方式了，因为这是可视化模式的主要盲区。表达式的作用，往往就是作为一个小功能点，而如果我们用可视化模式实现一个真假表达式这样的小功能点，就像是拿大炮打蚊子，性价比极低。

可视化模式更适用于实现连续性的、复杂的逻辑。一个实际的 App 会包含许多这样的大块逻辑，并且这些大块逻辑之间充满了缝隙，需要使用表达式来“粘连”在一起。比如下面这个场景就是一个很好的例证：

这个图展示的是用可视化方式编排一个逻辑判断的功能。我们都知道，逻辑判断功能最关键的一个点是要判断真假，但是用可视化方式来编排出真假的结果，却并不容易。因此，这个例子中，我们直接就让应用开发人员填写一个表达式，这个表达式将用于计算出这个条件的真或假。这个例子给出的混合方式非常自然，即使是没有多少开发经验的应用，也能很快掌握。

还是同一个例子，我们来看看采用纯可视化的方式是如何来完成真假判断的：

这张图是在判断一个数组是否为空（即长度是否为 0），可以看到，纯可视化方式在这里就显得啰嗦一些了，这样的一个表单最终只生成了 array.length == 0 这样一个表达式。

那么常见的表达式还有哪些呢？除了真假表达式外，还有三目运算、正则表达式、求值表达式、逻辑运算、数值计算等，很多，我就不一一列举了。

这些表达式都很适合与可视化模式混合使用，不仅可以作为可视化模式的有用补充，在生成代码时，往往还起到直接表达业务逻辑的关键作用。表达式与可视化混用是如此常见，以至于如果我不指出来，你也许都不会注意到这也是一种混用场景。

也许你会反驳：表达式不算是高代码。那接下来，我们就来说说有点“代码含量”的情形：代码块。

可视化编程是可视化模式中最难做好的一个功能点。在上一讲中，我给出了一种通过形象化的方式来表达和编排程序逻辑的方法，但是那种方式主要是给程序编程能力很弱的人使用的，一般能写点代码的人会更乐意直接编码。

我认为，代码块就是可视化编程功能中实现高低代码混合的最好方式。我这里说的代码块指的是若干行完整代码组成的、有特定功能的程序块，一个函数可以包含一个或者多个代码块。比如下面这个示例图中就包含了 3 个代码块：

在一个完整逻辑流程中，可视化逻辑块和代码块可以按需地交织混合在一起，如下图：

图中橙色块就是纯代码块，其他块则是可视化逻辑块。这种混合方式完全是由应用开发人员按需编排出来的：有可能是开发人员觉得某个功能使用可视化块效率更高；也有可能是他不知道如何写出符合预期的代码块，而不得不用可视化块；还有可能是没有合适的可视化块，而不得不使用代码块顶替；甚至有可能随编排时的心情状况随机挑选了一种方式。总之，可视化编排器需要能支持这样一种高低代码混合的方式。

也许你还要反驳：代码块的“代码含量”依然不足，不能算作高低代码混合。

那接下来，我们就说说纯度达到 24K 的高低代码混合方式。表达式也好，代码块也罢，都是在可视化模式为主导的开发流程中，使用少量代码作为辅助的方式，也难怪会被质疑这样的方式不是纯编码。

那“代码含量”纯度为 24K 的开发方式是啥呢？总不能和我前面自爆的 Awad 黑料一样，把 App 整个工程的代码都生出来，让应用开发导入到 VSCode 这样的 IDE 继续完成剩余的开发吧？

揭开谜底之前，我先介绍一下我为切分 App 工程代码设定的粒度：模块。一个完整的 App 工程由多个模块组成：

你可以从这张示意图中看到：

• 一个 App 工程至少包含一个模块，也就是图中最中间的启动模块，启动模块有且只有一个；
• 模块有多种不同的类型，而且各类型模块的数量按照 App 所需创建；
• 模块是 App 工程的唯一一种粒度。

其实还有几点要注意，不过这几点与这讲内容关系不大，所以我没有画到这张示意图上，但作为模块的重要知识，我们略微扩展一下：

• 模块之间可以相互引用，一个模块可以引用多个其他模块，也可以被多个模块引用；
• 启动模块由框架直接引用；
• 模块是实现 SPA（单页面应用）、应用自定义组件等的重要入口。

为了减少 App 开发的学习成本，我吝啬地只用了模块这一种粒度，它承载了切分 App 工程、实现 App 代码复用、做各种关键功能入口的职能。关于模块如何做到如此复杂的职能、但又以极轻量的面貌展示在 App 开发人员面前，如果你觉得有需要详细说明，可以在留言区留言，有需要的话我会用专门一讲来介绍。

好了，收回来。介绍了模块后，不需要我多说，你应该已经猜到了，我所说的“代码含量”纯度为 24K 的开发方式，就是按需将一个模块的开发方式从可视化方式，切换为纯代码模式：

上面动画演示了将当前模块的开发模式，从可视化模式切换为纯编码模式的过程。通过这样的操作方式将一个模块彻底转为纯编码模式之后，App 开发人员就可以按照纯代码的方式，继续完成这个模块剩余的开发工作了。

由于这里我生成的代码是基于 Angular 的，因此 App 开发人员必须严格按照 Angular 的方式来编码。他可以按需创建新的 Angular 组件，或者引用已有的组件来完成他剩余的开发工作。这是一种非常纯粹的编码开发模式了。

提示：如果你熟悉 Angular，你会发现我这里提及的“模块”这个概念和 Angular 里的“组件”的概念是对等的。

特别需要注意的是，切换成纯编码模式这个动作只影响当前模块，其他模块依然保持原有开发模式。并且，通过纯编码开发的模块可以继续被其他模块引用，它也可以继续引用已有的模块。也就是说，从 App 整体来看，它的开发模式就出现了高低代码混合的局面。

高低代码如何混合编译？

老生常谈，我再强调一遍，低代码平台的开发过程是有代码参与的。因此，如果低代码编译器能够生成对人类友好的代码的话（方法见【第 7 讲】），把一个模块切换为纯编码方式的难度并不大。难的是如何实现高低代码混合编译，进而实现高低代码所见即所得的效果。

接下来我们就来简要说说如何实现，限于篇幅，只能把思路说清楚，而无法给出代码级的指导，如果你实现过程碰到了什么问题，欢迎在留言区提问。

我在【第 6 讲】的“生成代码总体流程”的部分有提到，如果低代码平台实时渲染视图采用的是直接法，也就是直接生成浏览器能识别的代码并渲染出视图，实现高低代码混合下的所见即所得效果就会非常麻烦。反之，如果采用的是间接法，即先生成某种 MVVM 框架下的代码，再实时编译成浏览器能识别的代码并渲染视图的方式，实现所见即所得则会简单许多。

间接法下从代码到视图的流程

从实现的流程图上看，采用间接法时，高低代码混合模式的编译流程几乎是一致的，因此实现起来非常容易。这个流程图是以代码为视角来画，如果改从所见即所得效果的实现过程来看的话，这个图应该进一步细化为这样：

这张图中指出了各个关键环节之间采用了哪个编译器来处理：

1. 编译开始于用户配置数据 SVD，使用低代码平台的编译器 awadec 将 SVD 编译成 TypeSript 代码；
2. 如果是纯编码模式，则不需要 awadec 的编译，手工敲出来的就是 TypeSript 代码；
3. 接下来使用 tsc 编译器将 TypeSript 代码编译成 JavaScript 代码；
4. 再调用 Angular 或者其他 MVVM 框架的 JiT 编译器将 JavaScript 代码编译成组件描述符；
5. 然后交给 MVVM 框架的渲染器，它会生成 DOM，并驱动浏览器渲染成视图。

其中第 3 步将 TypeSript 代码编译成 JavaScript 代码的这个过程，目前看只有你使用 Angular 才会有，虽然 Angular 也支持 JavaScript 风格的 API，但官方不建议使用。因此我建议你采纳这个建议，先生成 TypeSript 代码。

如果你选用的是 React，那虽然没有 TypeSript 转 JavaScript 这步，但要多出将 JSX 转成 JavaScript 的步骤。如果你选用了 Vue2 就不用将 TypeSript/JSX 转 JavaScript 了，但现在 Vue3 也拥抱了 JSX，又需要有这一步了。

之所以把这个过程写得这么详细，主要是因为，为达到所见即所得的效果，代码从编译到视图实时渲染的全过程都有非常高的性能要求。因此建议你和我一样，将整个编译过程全部前置到浏览器中完成。但这样做就需要摸索出如何在浏览器中完成这所有步骤的方法了。其中 TypeSript 转 JavaScript 的详细方法，我整理成了一个 PPT，放在这里。你需要的话，可以参考。

而从 JavaScript 代码一路到浏览器视图渲染之间的步骤，我这里就不详细展开了。这部分和 MVVM 框架选型有直接关系，我用的 Angular，考虑到在国内 Angular 是小众，因此我的经验不一定是你需要的。当然，你也可以在留言区留言，如果很多人都需要的话，我可以专门找一讲来说清楚，这部分的难度其实还挺高的。

这部分的最后，我直接回复一下一个我被问了无数次的问题：一个模块被转为纯编码模式后，还能再回退到可视化模式吗？

答：不可能！可视化编程总是要有一些条条框框来约束的，而一旦转为纯编码模式后，等于放飞了思维，人的思维有多复杂，就有可能写出多复杂的代码来。因此一旦冲出了可视化编程设定的条条框框，就再也收不回去了。

追问：那有没有办法给出一些约束条件，在满足约束条件前提下可以再回退到可视化模式？

答：目前我还没仔细去思考这个问题。如果给出很强的约束那当然是可以的，但人的行为是不可控的，因此不可能给出太强的约束条件，我们需要设定出一些对人类非常友好的、简洁的规则来。关键原因是，目前我们没有这样的需求，使用可视化模式 + 代码块已经可以完成绝大多数的开发需要。

如何提升编码体验？

编码体验是纯代码模式下一个绕不过去的话题，这个话题往往是你好不容易走通了高低代码混合模式后，欣喜若狂之时的一盆冷水。

从高低代码混合的功能来说，编码体验不能算是一个问题，但在实际编码过程中，如果没有代码智能提醒、补齐、出错提醒、全局搜索、重构等功能，想象一下，这还算是在写代码吗？现代的编码 IDE（IntelliJ/WebStorm/VSCode）已经把纯代码开发开发人员的胃口给伺候得极其刁钻了。

在低代码平台上的高低代码混合开发，即使在编辑一个表达式，至少也就需要有智能提醒、补齐、出错提示了。如果使用了代码块的混合方式，那么这方面的需求比较强烈了。到了模块级的纯编码，那此时的编码体验的要求，就基本和 Web IDE 甚至和 Native IDE 相似了。难道要求我们在低代码平台上做一个 VSCode 出来吗？

怎么办？我们分成两种情况来讨论。表达式和代码块属于比较轻量混合，我们放一起讨论，而模块级的纯编码混合方式作为另一个情况单独讨论。

表达式和代码块对编码体验的要求其实已经不低了，但还没到非常极致的情况，因此只要有一个足够强大，扩展性足够强的编辑器，应该就可以应付。

这方面我走过一些弯路，过程直接跳过，我直接告诉你结果。我最终选择了Monaco这个开源编辑器，即使你没听说过这个名字，你也有可能已经是它的深度用户了，它就是 VSCode 的底层编辑器。功能自不必说，主要是扩展性极强，可以玩出非常多的花样，所以我们引入 Monaco 编辑器用于应对表达式和代码块场景的编码体验就完全足够了。

不过模块级的纯编码混合方式对编码体验的要求就非常高了，基本和 IDE 在同一层级了。此时，有两种可能的选择，一是继续基于 Monaco 编辑器，为它加上各种功能和扩展，深入将它融入低代码平台。这样做的好处是集成度非常好，低代码平台提供了一站式的开发体验。代价也是显而易见，你需要投入大量的资源来扩展和定制 Monaco 编辑器，把资源投入在这个方面，是低代码平台所需的吗？

另一个可能的选择是，把球踢给某个 IDE，比如 VSCode，我们需要的功能，这些 IDE 已经都有了，而且做得已经足够好了，我们只需要想办法利用这些 IDE 即可。

那如何做到平滑地复用呢？插件，任何现代 IDE 都支持插件。所以，我们可以基于某个 IDE 做个插件，用来从低代码平台过渡到 Native IDE 上。这个方式的成本比较低，具有很高的可行性，但缺点就是集成度不是很好。特别是在各个 App 开发人员的电脑上安装 Native IDE 和插件，有可能会有一些不必要的困难。

总结

今天这讲，我们详细讨论了低代码平台式的高低代码混合开发模式，“代码含量”从低到高分别是表达式、代码块、模块级。总体来说，高低代码混合的开发方式是低代码平台上非常有必要的能力，特别是需要对表达式、代码块这两种混合方式提供良好的支持。无论低代码平台处于哪个发展阶段，刚起步也好，已经成熟也罢，我认为低代码平台对表达式和代码块的混合的支持都是必须的。

表达式和代码块这两种高代码开发方式，在低代码平台上的实现方式是相似的，都是以可视化的低代码开发流程为主。在可视化方式的不可达或者友好的位置，使用表达式或者代码块来填补，两种方式可以非常好、非常自然地融合在一起。而模块级的编码模式，则是彻底丢弃可视化模式，转为纯编码开发方式，尽管如此，在纯编码开发的模块也可以和可视化开发的模块混合使用。

在完成了高低代码融合之后，编码体验是我们不得不面对的一个问题。好的编码体验可以提供更高的开发效率，减少试错的次数和避免部分低级问题。但要获得好的编码体验并不容易，虽然我们引入 Monaco 这样的编辑器，可以利用其强大的基础功能和扩展能力来有效提升编码体验，但是需要有一定的扩展的工作量。

我建议你使用 Monaco 编辑器来解决表达式和代码块的混合。而模块级的纯编码模式，虽然 Monaco 编辑器也能搞得定，但是扩展工作量会很大，还不如牺牲一些集成度，给 VSCode 等 Native IDE 做插件，从而最大化利用这些 Native IDE 的已有能力。

虽然这讲到这里的篇幅已经非常大了，但是这个话题依然还有许多必要的内容没能讲到。包括：

• 高代码模式下如何处理存量代码？
• 如何扩展 Monaco 编辑？
• 如何开发 VSCode 插件？
• 如何处理好第三方依赖？

后续等有机会我们再翻出来说清楚这些内容。

思考题

你认为提供模块级的纯代码开发模式有多大的必要性？请结合你的场景聊聊你是怎么看的。

欢迎你在留言区写下你的想法，下一讲我们将会来讨论 App 开发过程中数据配置的问题。我们下一讲再见。