治理边界与常见反模式

低代码擅长：
  - 结构化数据的增删改查
  - 表单录入与校验
  - 审批流程
  - 报表与看板
  - 内部工具

低代码不擅长：
  - 复杂交互（实时协作、富编辑器）
  - 高性能计算（实时渲染、大规模计算）
  - 深度集成（私有协议、复杂事务）
  - 面向海量 C 端用户的产品
  - 高度定制的前端体验

退回信号（出现任一即应评估退回）：
  1. 为表达一个需求写了超过 3 层嵌套的表达式
  2. 需要插件/自定义组件才能完成核心功能
  3. 元数据 JSON 比等效代码还长
  4. 调试需要「脑内执行」元数据
  5. 性能优化只能靠改平台内核
  6. 同一个需求反复改配置仍不稳定

退回方式：
  - 局部退回：把该模块做成插件/自定义组件
  - 整体退回：用代码实现，平台只做集成
  - 混合：平台管结构，代码管逻辑

路径 1：复杂度转移
  平台的复杂度没有被消除，只是从代码转移到了元数据
  元数据越长越难懂 → 最终比代码更难维护

路径 2：边界侵蚀
  每一次「就这一次特殊处理」的妥协
  累积成平台里大量的一次性分支

路径 3：治理缺位
  应用/插件数量失控，无人盘点、无人下线
  平台变成「数字垃圾场」

现象：
  元数据里出现嵌套十层的条件表达式
  用「变量 + 循环 + 条件」模拟编程语言
  配置文件长达数千行

原因：
  平台提供了「万能表达式」，用户拿它写程序
  DSL 失去了「领域特定」的约束

规避：
  1. DSL 保持领域特定，不追求图灵完备
  2. 复杂逻辑引导到代码（插件/自定义函数）
  3. 表达式长度设上限，超限提示重构
  4. 提供「提取为函数」的重构能力

# 反模式：用配置模拟编程
when: "{{ a > 1 && b < 2 ? (c == 'x' ? d : e) : (f && (g || h) ? i : j) }}"

现象：
  每个垂直需求都写一个插件
  插件数量超过平台内置能力
  插件之间互相依赖、版本冲突
  没人知道哪些插件还在用

原因：
  扩展点太粗，任何需求都要写插件
  缺少插件治理（审核、盘点、下线）

规避：
  1. 扩展点细化，让「配置」能覆盖更多场景
  2. 插件上架审核，控制质量与数量
  3. 插件使用统计，识别僵尸插件
  4. 定期盘点，下线无使用插件
  5. 核心能力不进插件（插件是可选的）

现象：
  半年内应用数量从 10 涨到 1000
  大量应用创建后无人访问
  没人知道哪个应用还在用、谁负责
  改一个数据模型不知道影响哪些应用

原因：
  创建成本极低，无准入门槛
  无生命周期管理（无归档、无下线）
  无归属（没有 owner）

规避：
  1. 准入：创建需说明用途与 owner
  2. 归属：每个应用必须有负责人
  3. 盘点：定期扫描访问量，标记僵尸应用
  4. 下线：长期无访问自动归档 → 通知 owner → 删除
  5. 依赖图：改模型前能查到影响面

-- 识别僵尸应用
SELECT a.app_id, a.name, a.owner, MAX(v.visited_at) AS last_visit
FROM app_metadata a
LEFT JOIN app_visit v ON v.app_id = a.app_id
GROUP BY a.app_id, a.name, a.owner
HAVING MAX(v.visited_at) < now() - interval '180 days'
    OR MAX(v.visited_at) IS NULL;

现象：
  有人直接连数据库改数据/改表结构
  有人用平台外的方式写数据
  平台元数据与真实结构不一致（结构漂移）

原因：
  平台缺能力（某个操作平台做不了）
  或者平台太慢（临时改数据比走平台快）

后果：
  校验被绕过、权限被绕过、审计断链
  结构漂移导致平台报错或数据错误

规避：
  1. 补齐平台的高频缺失能力（减少绕过动机）
  2. 数据库账号最小权限，平台外账号只读
  3. 结构漂移检测，定期比对并告警
  4. 审计日志，记录所有直连操作

应用分级：
  L1 试验：无准入，随时可删
  L2 正式：有 owner，进变更流程
  L3 关键：有 SLA，变更需评审 + 备份

分级驱动的治理强度：
  L1 → 基本不治理
  L2 → 变更需记录
  L3 → 变更需评审 + 灰度 + 回滚预案

# 治理清单
准入:
  - 创建需填写用途、owner、分级
评审:
  - L3 应用的模型变更需评审
  - 破坏性变更需二次确认
下线:
  - 180 天无访问 → 通知 owner
  - 通知后 30 天仍无响应 → 归档
  - 归档后保留 90 天 → 删除
盘点:
  - 季度盘点应用、插件、数据源
  - 输出僵尸清单与下线计划

健康度指标：
  - 应用数 / 活跃应用数 / 僵尸应用数
  - 应用 owner 覆盖率
  - 平均应用复杂度（字段数、表达式深度）
  - 插件数 / 活跃插件数 / 僵尸插件数
  - 结构漂移数
  - 变更频率与失败率
  - 退回率（有多少需求退回写代码）

健康信号：
  活跃应用占比 > 60%
  owner 覆盖率 > 95%
  僵尸插件 < 10%
  结构漂移 = 0
  退回率在合理区间（不是 0，也不是很高）

危险信号：
  僵尸应用持续增长
  无人认领的应用出现
  表达式深度持续上升

角色划分：
  平台团队：维护平台内核、扩展点、治理工具
  应用团队：用平台搭建业务应用，对应用负责
  治理委员会：制定规范、评审关键变更、决定下线

边界原则：
  平台团队不做业务应用
  应用团队不改平台内核
  需求撞墙时，走「退回写代码」而非「改内核」