【第2365期】程序员为什么不喜欢低代码？

作者：taowen

前言

低代码近几年曝光度也挺大的。今日前端早读课文章由乘法云CTO@taowen授权分享。

正文从这开始~~

提纲。总体上是两个大方向：

好的工程实践是有原因的，不会因为“低代码”了，之前的工程实践都不再适用
低代码不是纯技术能实现的目标，需要产品和技术一起努力

工程实践角度

比如说

版本管理
发布变更流程
单元测试
自动化测试
调试器
代码提示
出错提示，代码行号定位
common reuse principle 等依赖管理原则
...

我们把低代码换个说法叫“最终用户编程”。然后把最终用户看成一个开发团队。那低代码也是一种软件开发的形式，只是把最终用户这个软件开发团队引入到了软件开发过程之中了。传统的最佳工程实践都是有价值的，有必要在低代码这个语境下一一考量一下其意义。

这里投入不足，很大程度是因为做这些东西成本巨大。这里又牵涉到了，什么情况下值得弄个低代码出来，多少收益才能抵消成本。

产品和技术协作角度

低代码建立在“预制件”的基础上的，但是低代码没有说明这些“预制件”是从哪里来的。两种可能：

先有具象的需求，然后逐步归纳出预制件
先有预制件，然后把需求往里面套

当使用低代码是纯技术行为的时候，技术侧就会非常难受。因为低代码希望的是需求内在有规范有规律，可以被压缩成预制件。但是需求是啥样，那是产品经理说了算的。

无论是归纳出预制件，还是先有预制件再用预制件表达需求，可能都走得通。但是都不能是靠技术侧去推动产品侧，而是一起协作来搞，得有组织和流程的保障。

用 c 语言很难精确寄存器，用 java 很难控制内存，用 vue 很难高频率刷新 DOM 实现动画，一项技术总是有其代价。低代码也一样，总是会丧失一些适用范围和场合。技术选型的事情应该由解决问题的人，根据问题本身的需求选择技术方案，而不是被指手画脚。使用还是不使用低代码做为技术方案，应该像其他技术选型一样让解决问题的人根据需求来决定。先有需求，再有解决方案。

有时候不是把所有相似的代码都归纳成一个函数，就一定就能提效的。比如搞一个 DSL 解决界面组件联动问题。这样的 DSL 弄出来也就是一个 javascript 的变种。预制件不是你说那里可以弄一个出来，就一定可以弄一个出来的。压缩是建立在有规律，有冗余的基础上的。如果原来的表述方式已经足够精简了，就没有多少压缩空间。

程序员提效

我们可以从实现低代码的技术里寻找提效的手段，但不要把任何提效的努力都打上低代码的标签。

所见即所得的可视化编辑。修改了配置，立即生效。这样的低延迟的反馈周期是很好的开发者体验，值得借鉴过来。如果程序员所有的修改都可以不经过几十秒的编译构建就立即看到反馈，显然能提升效率。但这不意味着一定要做动态化解释执行。弄一个 JSON 出来解释执行，渲染界面，不意味着就提效了。恰恰相反，因为引入了动态化，运行时执行的过程会更复杂，整体的代码量会变大。

代码生成是常见的所谓 model driven 方案的特点。但是代码生成相对抽取函数的优点是什么有没有想过？函数要求自己在一个进程内执行（不能跨进程迁移局部变量），也不能执行太长时间（不能持久化下来，过几天加载回去接着执行）。函数同时也是一个编辑时的单元，把相关的逻辑合并到了一个总的索引下。当我们要把跨进程的逻辑合并到一个编辑时单元下的时候，就没有办法使用抽取函数的办法了。所以“代码生成”这个技术，或者“DSL”这个技术，允许的是更大的组织逻辑，分类整理的自由度。

另外一个代码生成的好处是如果用抽取函数的方式，函数的所有分支都要被阅读才能知道其行为，而代码生成可以仅仅关注生成后的代码实际是啥，而忽略生成器的复杂逻辑。

预制件的愿景让产品需求能够更有内在一致性。当程序员和产品经理都认同这几个功能都应该用预制件拼装出来的时候，就可以从源头上减少不必要的产品不一致性导致的额外工作量。所有的提效手段，最管用的还是砍需求。