最近一两年 lowcode（低代码）平台，如雨后春笋一样爆发出来。
每个公司都有几个、甚至几十个方案涌现出来，大家一起 “拖/拉/拽”，
有些人甚至戏谑说，这是时代的倒退，frontpage/dreamweaver 又回来了。
其实，拖拽 和 代码生成 方案，并不是最近才出现的，甚至成熟的方案十几年前也都有，
比如微软的 .NET webform，entity framework。
刚入行时我用过一段时间 webform，后来切换到了 .NET MVC。
webform 沿袭了 winform/vc++ 等系统软件开发的套路，
先用拖拽方式把视图做出来，然后再编写相应的逻辑代码，跟自家的 wpf 挺像。
entity framework 是一个 orm 框架，可以通过几种途径自动生成数据访问层代码，
用户不直接操作数据库了，而是操作一些领域对象，
从领域对象到数据库的所有样板代码，通过 entity framework 自动生成。
虽是如此，我仍觉得 lowcode 平台不是历史的倒退，而是螺旋上升。
着眼于整个研发过程
讨论事物的一个办法是，把它放到所处的环境中，看看它在哪个位置。
如果只看 lowcode 平台 的话，我们会认为它自成一派，可以独当一面。
但如果把看成是整个研发活动中一环的话，它的优势和局限性也就付出水面了。
研发流程通常以分析市场确定产品定位开始，然后制定产品规划，得到产品需求，
接着，工程师与产品经理合作，用语言/工具/框架 把需求实现出来，得到功能代码，
然后，通过一系列自动化的手段，进行依赖分析、编译、打包、部署、发布。
它分成了几个阶段：产品阶段 -> 开发阶段（编码） -> CI/CD 阶段 -> 用户使用阶段。
经常会涉及到这样一些平台，
研发平台：应用的生命周期
项目管理平台：快速交付价值
内容平台：知识沉淀、学习
编码辅助工具/平台：便捷的产出代码
而 编码辅助 方案则是多种多样的，比如说，
IDE：一个集成开发环境，提高代码编写效率
拖拽：图形化的方案，“写” 代码
脚手架/代码生成：使用编译方式生成样板代码
所以 “拖拽生成页面” 其实是属于 “编码辅助” 这一块（虽然它可以应用于其他领域）。
而 lowcode 显然比拖拽的意义更广泛，它是立足于 “编码” 的。
人们期望通过一种体系化的方式，减少编码量，降低编码门槛，来提高整个研发过程的产能。
为什么是螺旋上升
软件行业的发展有两方面是相辅相成的，一个是规模化效应，软件到了量产时代。
另一方面，则是基础设施的日趋完善，以前一些困难的工作变得越来越简单了。
关于基础设施，我拿编译领域来举个例子，
虽然在学校里有编译方面的课，但实际工作中，能写 parser 并对结果进行分析的人却很少。
这是因为有很多脏活累活，任何一个还算有用的语言的 parser 都很麻烦。
所以理论与现实之间有很大的差距，我们知道怎么做，但是做起来很困难。
如今时代发展了。比如，微软已推出了 .NET Compiler Platform 这是一个编译平台，
可能是受到 llvm 的影响，工程师们可以通过 compiler api 来进行编译方面的业务开发了。
前端领域，以前我们想获取 javascript 代码的符号信息，这是很难的，
因为不仅 js 解析起来麻烦（好多个版本），语义分析这一块也没有成熟的工具来做。
现在，typescript 采用了新的 compiler 架构，有很多 api 可进行上层开发。
所以，这一切正在悄无声息的发生变革，以前用 ReSharper 重构 C# 代码觉得很神奇，
现在可以用基于 compiler platform 写自己的重构工具了。
回到 lowcode 这边来，由于编译技术的开放和发展，
任何一家公司、团队 都有能力处理常用的编程语言了（例如 typescript），
所以事情就简单多了，语言的应用 跟 语言的基础设施 解耦了。
我们知道很多老牌语言的 IDE 是一体的，IDE 绑定了编译器，
比如 borland c++、delphi、vs studio，更早的比如说 smalltalk。
现在随着 lsp/dap 概念的提出，语言供应商 与 编辑器供应商 也开始独立发展了。
这就萌生出很多 语言基础 之上的其他类型的业务，比如说 web ide，比如 lowcode。
难点和考虑
语言方面的门槛越来越低了，可为什么我还要说 lowcode 依然难搞呢？
这是因为前端开发者们 涉足 code 领域的时间还太短，积累不足，
此外，很难同时站在 工程、编程语言、产品几块的宏观视角下看待问题。
比如说，lowcode 平台的产品定位是什么？服务哪些人群，哪些人不是我们的用户？
产品的范围定位不清，就会导致走很多弯路，不同的用户左右不讨好。
工程方面，lowcode 在整个研发过程中属于什么位置？
产物怎么与工程中的其他部分结合？
lowcode 平台中的 “代码” 如何测试？如何复用？如何跟 “手工编码” 做衔接？
很多 lowcode 平台用的人很少，在于没法把它放到现有生态中去。
语言方面，人们低估了创建一套 DSL 生态的成本。
之前我们说一些常用语言的 基础设施 完备起来了，但是还没到支持 DSL 这个阶段。
市面上罕有 语法设计器、DSL 的调试方案、DSL 语言服务、DSL 的编辑器。
所以我们虽然踏上了 lowcode 时代的风口，也要谨慎看待自家产品的选型。
能用简单的办法，不用复杂的办法。以能解决高杠杆率的问题为第一要义。
结语
lowcode 这个领域已经蓬勃的发展起来了，我还在学习中，
以上只是写了一下自己的看法。
最近几年 编译领域 也一直在尝试向应用层发展，
比如 jetbrains 的 mps。data-flow analysis 也逐渐走出了编译器，向安全等领域进发。
国内的几家 小程序，发展非常快，逐渐形成了一个行业。
lowcode 的潜在强交互性，刚好是前端工程师们所擅长的，
前端工程师天生离产品比较近，lowcode 也因此有了更多的业务场景，
这也就看出来为什么 lowcode 能成为最近几年的热点了。
山重水复疑无路，柳暗花明又一村。