中后台系统其实可以拆分成几个比较通用的场景：表单、表格、图表，
表单涉及到联动、校验、布局等复杂场景，是开发者的需要耗费精力去解决的点，
一套与之配套的技术框架和开发实践的落地方案。

设计开发是增加附加值的，无法单独存在，
技术必须长在业务之上。而连接更大的使命，就是找到更大的业务去产生更大的设计附加值
从业务视角看待，用户关注的是最终提供给终端用户的服务能力，用户不关心，你是大数据开发的，还是AI实现的，用户只要结果，告诉我，能不能用！

Web 是最贴近前端开发者的，无论是框架提供者，还是业务开发者都应该更多的从标准的角度思考问题，这样才能让业务代码有更多的可能性对于业务的开发者而言，「一码多端」才是效率最大化的主要表现为：人员成本，维护成本，跨端开发的学习成本，性能问题，线上审核发布的便利问题

首先要定义一个有效的问题，有痛点，有价值，有解决方案，定义了一个新的问题并给出了解决方案。
技术和时间方面的限制
真正解决用户的问题，第二需要持续的投入较多精力维护
这个场景下用户的问题是什么，我们以什么样的思路去解决这个问题，然后再反推我们的技术方案是什么

表单，流程表单，报表等办公类
报表搭建
流程搭建
DI报表，Data Intelligence，即数据智能

编辑器
发布
线上应用
分享
内嵌页面
数据调用
管理员负责搭建和管理，表单用户提交和审批，其他系统可以调用数据
完整的文档
长期维护的社群

表单领域多端一致

表单领域多端一致，搭建平台的对接成本，学习成本
前端框架统一，降低维护成本很高，组件间复用性低
PC端，H5端开发体验一致

  1. 技术统一，整合产品规范，降低重复劳动
  2. 支撑业务发展
  3. 版本迭代规划，业务方向聚焦
  4. 统一文档平台
    1. 研发流程，应用架构统一，代码发风格一致
    2. 代码规范，团队认同感
    3. 相似的代码风格，对 codereview和接手维护会更方便
  5. 沉淀技术栈，研发体系一致，包括
    1. 前端监控
    2. 自动埋点，上报sls日志，问题排查等。
  6. 变更应急
    1. 应急平台，故障列表，风险预警，封网管控
  7. 业务沉淀
    1. 组件沉淀：将页面模板，组件归类，产生前端PD理解一致的组件，页面模板库，上升到核心资产
    2. 统一术语规范，沉淀扩展已有前端组件库，提供专业的中台前端，设计，业务组件解决方案。

中后台表单规范


中后台页面的视觉一直以来不够重视，导致目前的UI问题比较突出：

  • 原生 html 组件开发的页面
  • 各种不同的 主题开发的页面
  • antd 开发的 UI 页面
  • 不同风格的表格、搜索、Tab 等视觉

解决
业务组件
统一的基础设计规范
统一的组件设计规范
统一的页面设计规范
风格的表格、搜索、Tab 等视觉

前端按领域划分，小而美，不要把一个应用做成巨型应用
一个平台可被所有业务复用，业务组件在平台内可被复用，减少重复开发成本
低耦合，高内聚：前端项目是多个特定业务小项目，业务单一，维护简单，多人协同开发成本较低。
前端加页面，后端加接口服务，通过配置中心配置就行
发布，回滚，通过修改配置中心就行
共用统一的前端组件库

每次开发一个中后台表单或者列表需求都要从零开发写代码，成本较大
大多数中后台系统都是由后端工程师维护的
产品功能频繁地变动，而有些变动可能只是加一个输入框或者改某个选择框的属性，但用源码的方式修改成本会很高

可视化搭建
搭建平台数不胜数，解决的问题也各不相同
通过强大的UI搭建能力提升页面编写效率的云端工作台。
5个后台项目的落地证明了目前这套从搭建到代码工作流的可用性
从头搭建页面的成本很大，对于后台场景，页面类型都比较固定，在现有模板上改比较从零开发效率高太多

缺少模板也会导致平台对新用户不够有吸引力
核心能力，丰富的素材与模板
接入素材中心
针对各类运营场景开发模板
对于水平差不多的团队，同类竞争或者同赛道的竞争很难分出优劣，尤其对于后来者更是如此。
因此在某些场景需要去探索新的方向实现弯道超车，但是如何找到新的方向，定义新的问题，进而解决这些问题是更加重要的。

表单物料
提高模板丰富度，用户基于官方模板可以快速地搭建出页面
覆盖中后台垂直领域 90% 以上的业务

表单基础属性，比如提交 URL、几个按钮以及按钮的操作
将 JSON 发布到后端生成一个 ID
前端请求 ID 取到 JSON
面向表单的场景搭建，快速地搭建出面向中后台垂直领域(如表单、列表等)页面需求
面向 PD 可视化场景搭建

表单系统的关键词

  • 电子表单
  • 表单可视化
  • 表单驱动
  • 表单引擎
  • 小程序表单搭建

https://www.zhisheji.com/jiaocheng/1646784.html
https://musicfe.com/form/
https://www.jianshu.com/p/da2155fbddd9
https://www.uisdc.com/long-form-design-3
https://blog.csdn.net/chinahuyong/article/details/120760438
https://www.zhihu.com/question/421374988/answer/2060013947
https://blog.csdn.net/loulanyijian/article/details/125347261
https://www.vyouke.net/2496.html
https://cloud.tencent.com/developer/article/1352743

表单场景

查询表单

客户端动作

  1. 校验表单
  2. 联动表单
  3. 跳转
  4. 提交

    提交表单

动态表单

用 json来描述表单；减少写表单的成本，提高开发效率

流程表单

制定标准或者约束

就像以前做活动页面，运营会在项目的各个阶段找你改这个改那个，
你的确有能力帮助运营一个个改完，但这是否是正确的方式？是否有更好的协作方式？
业务上的落地或者用户量一直处于一个相对低沉的阶段，最近一直在想如何去突破，没有一些成体系的结论，先把一些思考沉淀下来