目前大多数低代码平台，整个低代码应用包含了配置时（设计时）和运行时。
这种设计能满足大多数场景和用户的需求，但是并不能很好支持测试/生产多环境的发布部署。
B端大型企业，以及各种复杂项目，对系统的多环境有强烈的需求。即一套配置，可以应用到不同环境的运行时。
基于这种需求，很自然的拆分出一个配置中心，由配置中心分环境向应用的运行时服务同步配置。
但这个设计也会引入一个新的问题，运行时和配置时的边界是什么。
表面上看，运行时不会变更任何配置，只是配置的运行表现，因此和配置改动相关的都在设计时，比如字段、视图、枚举、权限、流等等。
但基于这种观点，衍生出来的各种设计，在实践的过程中被不短挑战和推翻。
下面举一些经典的例子，来讲讲运行时和配置时的区分难题。
常见的配置时/运行时区分难点
人员/角色
最常见的一个错误是，将人员看成是运行时数据，由该应用的运行时用户中心管理维护，这一划分在实践中会遇到非常多的问题，比如配置审批流时需要选择人员/角色，那这里的人员/角色是从运行时的哪个环境中来呢？
配置时数据有个特点：各环境key(id或code)一致，只是版本不一致。而运行时数据，不同环境key(id)不一样。
因此，我倾向于，将人员/角色的定义划分到配置时，并且配置时和运行时共用一套用户中心。这个设计可以避免配置时人员选择的难题。
枚举字典
枚举的定义总是在配置时，但枚举字段的维护，往往发生在运行时。
一个项目通过低代码平台开发完成并顺利交付，但交付仅交付产出物，并不会连同低代码平台一起交付。随着业务的开展和数据的增加，之前配置的枚举项可能并不能满足当前的业务场景了，此时就可能出现需要修改枚举的情况。
比如商品类型，平台上定义了10种，现在有业务需求新增一种。对客户来说，只要是数据，就应该能够自主维护，但对项目来说，这些是配置，必须由项目运维操作。
这个矛盾的核心是，枚举字典可以理解为配置，也可以看成是数据！
如果能理解这一点，那么可以进行如下设计：
在配置平台上可以新增枚举，并配置枚举项，配置发布后，枚举项作为运行时该枚举的初始枚举项，但不同的运行时可以维护/调整该枚举项内容。
视图展示/导出的字段/顺序
视图展示的字段、导出的字段、展示/导出的字段顺序，这些都显而易见是配置。
那么运行时是否有需要改动呢？当然是有的！
不同的角色分工，关心的字段不一样，A财务关注已发起字段，B财务关注已审批字段，因此不同的人对视图有不同的需求。
但这种需求不能理解为数据，应当看做用户习惯，即配置平台提供默认的视图，用户可自行调整部分展示效果。用户习惯可以简单的存在浏览器本地。
配置时/运行时划分原则
配置时该的数据，往往涉及到结构，比如字段增删、字段类型修改，而运行时改的配置，一般是配置数据，而不是配置本身。比如人员/角色加了几条数据，而不是人员对象加了几个字段。
因此可以基于这个特点决定该数据运行时/配置时的归属。
另外，如果数据归属于运行时，但又有多环境共用一套的特点，则可以单独抽离为一个服务。
感悟
配置时和运行时，看似简单清晰的分界，实践中有非常多的细节问题需要思考。
我们既不能站在谁改的多的角度进行划分，也不能强行设置变更流程/约定等方法简单的一刀切，而应该看清楚，运行时可修改的配置与其他配置的本质区别。
低代码平台的实践中，类似的不起眼的小问题很多，拍脑袋进行技术决策，后续就会寸步难行。
产品需求影响技术决策，技术决策决定技术实现，技术实现约束产品迭代。
作为低代码平台的开发，我常感觉，不管是什么需求，如何糟糕的设计，总能找到途径实现或者打上补丁。
然而越是这样做，后续的迭代越给我一种窒息感。有术无道，总有一天会走投无路。
作为产品，应该去了解技术实现思路，作为技术，需要抽象出不同的产品形态和技术路线背后的本质区别。这是我理解的低代码平台开发的“道”。
