2022年初，我加入公司低代码团队，负责视图部分。
彼时，低代码平台已初具雏形，整体框架明晰，基础也做的不错，功能规划有序推进。但低代码平台的功能并不完善，产线的接受度也不高。
平台配置的快速膨胀
加入团队将近两年时间里，我对视图增加了大量配置功能，以满足产线和项目各种需求。
到2023年底，低代码视图部分的功能基本完备，当年低代码平台搭建的页面占公司整体页面将近60%。24年开始，已经很少听到业务线反馈需要新增某某功能了。
然而此时再回顾视图部分，光列表视图就有170多个配置项，每个配置项可能有若干个配置点，这还不算工作流和中的action和各种控件。
强大而难用的低代码平台
配置规模迅速膨胀带来的副作用是，常有人来问，xx功能支不支持，xx需求如何实现。即使这些功能文档都有，甚至我还做了功能地图，但很多人仍然不知道对应的配置在哪里，xx功能如何开关。
如果以前觉得这个平台不好用，可能是功能过于简单，配置不满足，那么现在如果有人觉得这个平台不好用，大概率是因为配置太多了。
即使我已经注意到需要控制配置项规模，但复杂的业务诉求驱使你不得不开发额外配置。
就比如说导出功能，默认是导出列表中所有字段，格式为excel，文件名为对项目，接口是同步的，因此会有一些配置需求：
- 部分系统数据量大，需要配置成异步导出
- 部分系统要求支持导出csv，因此也增加了一个格式配置；
- 有部分系统的使用者需要自行决定导出哪些字段和顺序（比如不同的财务人员关注的字段不一样），于是运行时增加了导出模板的配置，还支持记忆功能
- 运行时的导入模板，希望加一些提示，于是又增加了一个自定义说明的配置
- 有些系统字段比较多，运维希望直接配置一个默认的模板，于是配置时也增加了模板控制
- 配置时的模板上，有些运维希望未勾选的字段，用户也不可见，但有些运维希望用户那边还可以自己勾选，于是又增加了一个配置项
- 有些用户对导出的文件名也有要求，希望增加时间/当前的状态页签
这些配置项看上去都很合理，事实上也如此，我们接到的需求，基本都是项目中提出来的，经过筛选后并不存在伪需求。
即使每个配置项都有实际业务背景和诉求，但并非每个配置项都能达到理想的使用频次。因此我开始思考，如何一方面控制配置规模和难度，尽量保持平台的易用性，另一方面能够支持各种复杂的业务需求。
如何限制配置项数量
鼓励二开
作为低代码平台，二开率一直是我们关注的一个重点指标，然而为了降低二开率而将一些不够典型的需求纳入到标准功能，是得不偿失的。
比如我们的表单，表单项支持分组，但有个项目需要对分组再增加一个备注。对这个项目来说，仅仅是增加几个文字，但这个需求如果是作为标准功能，那么就需要考虑，这个备注是否需要支持变量表达式、是否支持图标、备注的样式等等。
这种低频的需求，如果是按照标准功能的方式来实现，实质上相当于用平台的人力去开发一个项目需求。那既然如此，不如直接将它作为一个项目需求，按照项目的方式来实现：平台提供二开项，项目方出人实现这个二开。这里可能的一个问题是，项目方没有人来接这个开发点，这个也很好解决：平台提供一个人来完成这个二开。
这种解决方式，无论是项目方还是平台，都能得到最优效率。
提供兜底机制
上面这个方案在实践中经常会遇到阻力：项目方不允许二开。
对项目方来说，增加一个二开项目，会提高运维成本：非二开的云端项目，功能bug修复、优化等，都由云端负责，而二开项目则需要自己关注和升级。
那么还有一种方式可以解决：提供兜底机制。
所谓的兜底，就是除了可视化的配置，还可以通过代码完成自定义的特殊逻辑。
比如说查询条件的默认值，可能是一个固定值，可能是来自于微前端基座传入的payload，可能是用户信息中的值，也可能计算自url上的参数，对关系控件（比如select），可能设置为下拉框中的第一个选项。
如果默认值支持这么多场景的配置，那对用户来说就很难理解和上手。假设最常见的场景就是给定一个固定的默认值，或者从url参数上传递一个默认值，那么配置项就根据这两个场景进行设计。
那其他场景怎么处理呢？兜底机制！平台在此处提供编写js代码的口子，用户自行从上下文中获取到参数进行设置。
兼顾功能性与易用性
无论二开还是在线编辑代码，都需要一定的编程能力，这是否违背了易用性呢？我觉得并不是。
配置项考虑的场景越多，用户的配置难度就越大，学习意愿也越低。在我看来，特殊场景的配置难度，最好只让对应的项目方承担，平台要做的是减少该项目方的配置压力或二开难度。
为了少数场景的需求而牺牲多数场景的配置体验，这才是违背易用性原则。
