最近几年各种低代码平台越来越多了，但绝大多数低代码平台形态上大同小异，下图就是其中最经典的一种形态：
我将其归纳为通用型可视化搭建平台。
可能有相当多的低代码受害者接触的就是这种平台------配置复杂，不灵活，从在IDE里写代码变成在平台上写代码。
通用可视化平台的问题
这类平台最严重的问题是搭建复杂。拿最常见/通用的查询表格页面为例，一套查询表格，包括以下几个模块
- 查询栏
- 表格
- 操作栏（表头/表格/底部）
- 分页
模块之间常有交互，比如查询/分页/操作需要重新请求表格数据，那么就需要对这些交互/行为进行一一配置。
如下图所示，每个色块都是一项配置任务： 
坦白说，花在这些配置上的时间，可能会比写这些逻辑的代码更长。毕竟这种模板代码抄过来改一改就行。
而让一个新人来配置，甚至根本不知道需要做哪些配置。
究其原因，这种低代码的设计，并没有降低开发者的心智负担，提效极为有限。
搭建视图的心智负担
抛开低代码平台，如果自己写一个列表视图，至少需要考虑：
- 查询字段
- 表格字段
- 增删改查接口
- 分页
- 样式
切换到低代码平台，如果是一个前端开发来搭建列表视图，也是按照这几个点去配置。然而如果是一个后端开发，得经过多次尝试摸索才能明白里面的逻辑。
所以，这种低代码平台只是换了一个壳子的编辑器罢了。
低代码平台，要解决的不是降低样式和逻辑编程难度，而是降低开发的心智负担！
真正站在用户的角度看
用户选择低代码的原因是什么？是为了感受页面创建过程吗？当然不是！ 是为了减少通用/模板功能的开发，这部分开发，不仅包括静态页面的布局搭建，更包括页面内的交互逻辑和数据逻辑。
我认为平台侧应最大程度上减少用户的决策和思考 ，直接提供模板/固定布局/界面/交互/功能------用户不再关注具体细节和数据逻辑，更多考虑字段设计/功能组合这类更偏业务层的问题。
以下是我理解的，较为理想的用户/平台分工：
基于该分工，视图配置的界面和交互可能是如下形式
聚焦核心，包容局限
没有哪个低代码平台能解决所有问题，但总有一些人试图在平台上解决所有问题。因此会出现很多极端的设计：
- 在平台上写大量代码以实现特定逻辑
- 在平台上管理Redis/MQ等
- 对样式配置细化到边框/边距/背景/字体
我认为，低代码平台，可以提供简单的函数级编程能力，再复杂一点的，比如组件/性能，要么抽象为通用能力，要么提供其他二开或兜底机制。
低代码平台始终解决通用问题的开发/维护负担 ，对于非通用问题，鼓励自行二开。
不吐不快
很多所谓的低代码平台，我看了之后特别想吐槽，技术上缺乏抽象，产品上缺乏担当，体验上强奸用户。
低代码平台，无论是功能抽象还是功能设计/交互体验，本质上都是替用户理解，替用户决策。
担当！担当！担当！
决策常有取舍，因此常有风险，但不能因为风险，而不敢决策。平台要有担当！
功能局限未必是低代码平台的缺点。比如轻流/明道云等，根本配置不出复杂和精细功能，但仍然有大量用户愿意购买。
而打着大而全的口号，把各种细节都交给用户自行决策的低代码平台，背后是一群缺乏担当的鼠辈，他们又如何能真正做好产品呢？