Admin Frontend Evolution
ODTS-42: 运营后台前端演变（new-edsweb, 2021-2026）
目标读者：想要理解 CICC OTC 衍生品系统的”隐形前端”——即运营/后台（Back Office）使用的管理界面——的 BA/PM
数据来源：
odts1/new-edsweb的 git 历史、package.json、路由配置关键结论：当所有人的目光集中在交易员前端（odts-linear-web）时，这套 Vue 2 管理后台默默支撑了 40+ 个运营模块、41 位开发者的协作，是系统中最”安静但不可替代”的项目。
概述
new-edsweb 是一个运营后台前端项目，面向以下用户群体：
| 角色 | 使用场景 |
|---|---|
| 运营（Back Office） | 结算确认、资金划转、银行流水处理 |
| 风控（Risk） | 风险指标监控、风控邮件配置、黑白名单管理 |
| 合规（Compliance） | 交易台账审查、信用风险对账 |
| 财务（Finance） | 估值报告、中证日报报送 |
| 客户服务 | 客户信息管理、开户申请处理 |
| IT 运营 | 数据同步监控、交易日历维护 |
它和交易员前端（odts-linear-web）的分工是：交易员看的是”当前持仓和交易”，运营看的是”生命周期内的所有记录和操作”。
为什么要叫”new”-edsweb？
这个项目名暗示了它的历史定位——在老系统 odts1/edsWeb（一个纯 JSP 项目）的基础上做的 Vue 前端重构。new-edsweb 不是替换交易界面的（那是 odts-linear-web 的工作），而是替换原 edsWeb 中的运营管理页面。
时间线
2021 年 9 月：诞生
第一次上传远程vue的odts项目第一条 commit 消息就道出了它的本质：把原有的运营管理页面从 JSP 搬到了 Vue 2。
初始技术栈：
- Vue 2 + Vue CLI ~4.5.0
- Element UI 2.x
- Vuex 3.x
- axios
- DevExtreme 20.2（商业表格组件）
- vxe-table 3.5.8（国产轻量表格）
- jqGrid 4.15 + jQuery 3.5（从老 JSP 页面带过来的遗留依赖）
这是一个务实的选择。Element UI 在当时是国内 Vue 生态中最成熟的企业级 UI 框架，DevExtreme 则用来处理 JSP 时代那些复杂的 Excel 导出和打印需求。
2022 年：快速扩张期（1,189 commits）
2022 年是 new-edsweb 的大扩张年。路由数量从最初的几个增长到 40+：
新增模块（2022）：
├── bankFlow 银行流水
├── foreignExchange 换汇
├── valuationReport 估值报告
├── sacReportDaily 中证日报
├── blackOrWhiteList 黑白名单
├── riskIndicators 风险指标
├── customerInfo 客户信息
├── tradingCal 交易日历
├── bonusRule 分红规则
├── nominalPrincipal 名义本金
└── ...这一年出现了大量以 req-、fix_ 开头的分支，需求驱动开发的典型特征：产品经理提一个需求，开一个分支，做完合并，然后分支永远留在 remote 上。
2023 年：稳定期（982 commits）
2023 年进入稳定迭代期，新增模块减少但维护工作量增加。出现了 ODI 变更编号（如 [350136]、[354940]），说明团队开始使用更规范的变更管理系统。
2024-2025 年：慢速维护期（564 + 392 commits）
2024 年后新功能开发减少，转入维护模式。新增的 ODTSPB-xxxx 系列分支（约 40 个 feature 分支）以 PB 业务优化为主：
ODTSPB-2609 DMA 多空合约展期
ODTSPB-1252 PB 风控邮件设置
ODTSPB-1350 PB 风控邮件自动发送
ODTSPB-1473 确认框优化
ODTSPB-1541 结算明细查询放开限制
ODTSPB-1797 事件管理 BUG 修复
ODTSPB-2026 利率重置
ODTSPB-2337 手动利率重置优化
ODTSPB-2951 指定合约展期
ODTSPB-3176 结算明细增加科目
ODTSPB-3239 报送相关
ODTSPB-3393 风控邮件支持 INTRADAY
ODTSPB-3623 中证日报批量操作
ODTSPB-4985 MO 科目划转
...2026 年：仍在维护（103 commits）
2026 年该项目的 commit 仍在上新（截至 7 月）。对比同年新建的 odts-linear-web（Vite + Vue 3 + AG Grid），new-edsweb 没有迁移到新框架的迹象。
这是一个关键的业务决策：运营后台的 UI 交互复杂度远低于交易员界面。它不需要 AG Grid 的虚拟滚动和实时数据管道，Element UI 的表格和表单在当前使用场景下完全够用。迁移的成本（30 个模块的全面回归测试）超过了收益。
项目规模
Commit 分布
| 年份 | Commits | 活跃开发者数 |
|---|---|---|
| 2021 | 250 | - |
| 2022 | 1,189 | 10 |
| 2023 | 982 | 16 |
| 2024 | 564 | 15 |
| 2025 | 392 | 4 |
| 2026 | 103 | - |
核心贡献者（按 commit 数）
| 开发者 | Commits | 角色推断 |
|---|---|---|
| Yu Zhao | 747 | 主力开发 / 架构 |
| DOUBLE | 524 | 前端开发 |
| Shanshan Wu (IT) | 294 | 前端开发 |
| Jiakang Wang (EQ) | 220 | 前端/业务 |
| denglei | 211 | 前端开发 |
| Yug Wang (EQ) | 172 | 前端/业务 |
| Zhushi | 152 | 前端开发 |
| Lijunjie3 | 88 | 前端/运维 |
| Jianfeng Zhang (EQ) | 86 | 前端/业务 |
| 1步 | 81 | 前端开发 |
| Lishuang | 81 | 前端开发 |
项目总共涉及 41 位贡献者——对于一个内部运营系统来说，这是一个相当庞大的开发团队规模。
代码规模
src/
├── api/ → API 接口层
├── assets/ → 静态资源
├── components/ → 通用组件
├── layout/ → 布局组件
├── mixin/ → 混入逻辑
├── router/ → 路由配置（40+ 路由）
├── store/ → Vuex 状态管理
├── utils/ → 工具函数
└── views/ → 29 个视图目录
├── BankFlow/
├── NominalPrincipal/
├── balanceCheckInfo/
├── bankAccountApply/
├── blackOrWhiteList/
├── bonusRule/
├── cashTransfer/
├── confirmationAttachmentISDA/
├── confirmationStamp/
├── connectionEndValuation/
├── customerInfo/
├── customerInfoSync/
├── dailyOpManagement/
├── eod/
├── eventManagerNew/
├── fiConnectionEnd/
├── foreignExchange/
├── indexQuote/
├── innerOpenAccount/
├── pbMoSubjectTransfer/
├── riskIndicators/
├── riskyConfTempManagement/
├── settlementDetailQuery/
├── syncServiceFee/
├── taCorrelation/
├── tradingBookSummary/
├── tradingBookeffect/
├── tradingCal/
├── underlyingSubscribe/
└── valuationReport/技术栈分析
版本锁定策略
package.json 中的依赖版本全部是精确版本号（无 ^ 或 ~ 前缀）：
{
"element-ui": "2.15.10",
"axios": "0.21.1",
"vue": "2.6.11",
"vxe-table": "3.5.8",
"bignumber.js": "9.0.1"
}这说明团队吃过依赖升级的亏，或者在严格的金融合规环境下不允许自动升级。
遗留依赖
<!-- 来自老 JSP 系统的借用 -->
free-jqgrid 4.15 → jQuery 表格
jQuery 3.5 → DOM 操作new-edsweb 的某些地方直接借用了 eds-web-app JSP 页面的表格组件。这在新前端中是罕见的——通常你会用 Vue 组件重写一切。但在金融系统中，功能正确优先于代码优雅，如果老组件工作正常，就没有必要重写。
缺失的 TypeScript
与 odts-linear-web（70%+ TS 覆盖率）不同，new-edsweb 完全没有 TypeScript。这是一个有意的取舍：
- new-edsweb 创建于 2021 年，当时 Vue 2 + TS 的工具链还不成熟
- 运营系统的类型安全需求低于交易系统
- Element UI 在 JS 下的集成成本远低于 TS
开发工作流
分支策略
从分支名称可以还原出清晰的工作流：
test_release → 集成分支（长期）
├── tj-xxxxxx → 普通需求/缺陷修复
├── feature/ODTSPB-xxxx → PB 业务专项
├── fix_xxx → 临时修复
├── req-xxxxx → 需求编号
├── fix/opt-release-xxxxx → 期权发布分支
├── release_vue_xxxx → 版本发布分支
└── testing_xxx → 临时测试分支三条主干
| 分支 | 用途 |
|---|---|
test_release | 日常集成分支（活跃开发） |
release | 生产发布分支 |
master | 归档分支（从 test_release 同步） |
CI 集成
package.json 中的依赖 @ctie/browserslist-config 和 @ctie/code-specification-unid 指向内部 npm registry @ctie，说明团队有统一的代码规范和浏览器兼容策略。
与 OTC 衍生产品系统的关系
new-edsweb 不是一个孤立的 UI，它是一个前端集成平台——通过 axios 调用 eds-web-app 的 REST API 来操作业务数据：
new-edsweb (Vue 2)
│
├──→ eds-web-app REST API
│ ├── /api/valuation/settle → 估值结算
│ ├── /api/settlement/query → 结算查询
│ ├── /api/contract/rollover → 合约展期
│ ├── /api/risk/indicators → 风控指标
│ ├── /api/report/sacDaily → 中证日报
│ └── ...
│
├──→ sac-report API (部分功能)
│ └── /api/report/submit → 报送提交
│
└──→ 直接文件下载/上传
└── 确认书 PDF、估值表 Excel不是 SPA，而是 MPA 风格：每个功能模块本质上是一个独立的页面集合，通过顶部菜单切换。这与 odts-linear-web 的 SPA 设计形成鲜明对比。
业务经验教训
1. 运营模块不需要交易级的实时性
new-edsweb 40+ 的模块中，绝大多数是表单+表格+报表的 CRUD 组合。不需要 AG Grid 的虚拟滚动、不需要 WebSocket 实时推送。Element UI + vxe-table 在运营场景下是合理的选择。
2. 内部工具的生命周期比想象中长
2021 年 9 月创建时，可能只计划运行 1-2 年然后被替换。但 2026 年了，它仍然在生产使用。内部运营系统的替换周期通常是 5-8 年，一个正确设计的框架选择（Vue 2 + Element UI）可以支撑很长时间。
3. 33 人协作一个 Vue 2 项目的可维护性
41 位贡献者、40+ feature 分支、没有 TS——这在传统前端项目可能会是噩梦。但 new-edsweb 之所以可以维持，是因为：
- 功能模块天然隔离：估值模块和银行流水模块的开发人员几乎不需要交互
- Element UI 约束了 UI 复杂度：组件库的选择决定了交互模式的上限
- 运营流程稳定：结算确认的页面在 2022 年做好后，2025 年只需要微小调整
4. 为什么没有被 odts-linear-web 替代？
这个问题的答案揭示了系统的隐性架构决策：
| 维度 | new-edsweb | odts-linear-web |
|---|---|---|
| 用户 | 运营/风控/财务 | 交易员/销售 |
| 交互 | 表单+表格+报表 | 实时网格+仪表板 |
| 性能要求 | 秒级响应 | 毫秒级+实时 |
| 技术栈 | Vue 2 + Element UI | Vue 3 + AG Grid |
| 模块数 | 40+ | 27 |
| 替换成本 | 低（模块独立） | 高（交易核心） |
两个前端项目并行存在、互不替代。新项目不是旧项目的”升级版”，而是服务于完全不同的用户群体和交互模式。
业务代价：这套”安静”的后台其实很贵
Vue 2 已经走到生命周期尽头（EOL）
new-edsweb 基于 Vue 2.6.11。Vue 2 官方已于 2023-12-31 停止维护，不再接收安全补丁。而 new-edsweb 在 2026 年仍在生产运行——意味着它跑在一个官方已停更 2 年以上的框架上。
风险：
→ 框架不再修安全漏洞（与 47 文档的"依赖风险"同源）
→ Element UI 2.x 同样进入维护模式，新浏览器兼容问题无人兜底
→ 一旦某个底层依赖（如 jQuery 3.5、jqGrid 4.15）曝出 CVE，
没有上游补丁可升
业务含义（PM/BA 视角）：
这不是"技术债"四个字能带过的。
一个支撑 40+ 运营模块、结算/报送/风控的核心后台，
跑在 EOL 框架上 = 监管口径下"关键系统缺乏安全维护"的潜在审计项。
迁移到 Vue 3 的成本文档估在"30 个模块全面回归测试"，
但真正贵的是：41 位开发者里大部分已不在原团队，
知识随人离职而流失（见下节"人员流失"）。没有 TypeScript 的 41 人协作 = 隐性 Bug 成本
ods-linear-web 有 70%+ TS 覆盖率，new-edsweb 完全没有。在 41 人、3,499 commits、40+ 分支的规模下，缺类型系统意味着：
→ 一个字段改名，要 grep 全仓库靠人眼找引用
→ 接口字段对不上（前端传 A、后端收 B）只能在运行时（用户操作时）才暴露
→ 运营页面错的不是"显示"，而是"写错了结算数据"——见下
PM/BA 启示：
交易系统（linear-web）上了 TS，运营后台（new-edsweb）没上，
不是因为运营不重要，而是因为"当时 Vue 2 + TS 不成熟"。
这是一个 2021 年的权宜，到 2026 年成了结构性负债。
评估任何"内部工具"时，类型安全不是锦上添花，是 41 人协作的刹车片。分支 sprawl：40+ feature 分支永远留在 remote
文档提到 req-、fix_、ODTSPB-xxxx 等分支”做完合并，然后分支永远留在 remote 上”。这是需求驱动开发的典型副产物，但它有真实成本：
→ 每个遗留分支都是一份"可能还没清干净的代码"
→ 新人接手时，分不清哪个分支是当前真相、哪个是历史垃圾
→ 一次安全审计要把所有分支都扫一遍——攻击面 = 主干 + 所有分支
业务影响（估算）：
40+ 长期分支，假设每个平均 0.5 人日清理/归档，
这就是 20+ 人日的"看不见的维护负债"，
而且它每天都在产生新的分支。人员流失：41 人里大部分已离开
核心贡献者 Yu Zhao（721+326 = 1,047 commits）一个人占了约 1/3。这种”核心一人扛”的结构，在人员流动时是最大的单点风险：
→ 一旦核心离开，交接的是 1,000+ commit 的上下文
→ 没有 TS、没有完整测试、分支散落——接手者只能边读边改
→ 与 37/41 文档的"前端世代混乱"同一根源：
知识沉淀在工程里，不在文档和人里
PM/BA 启示：
"谁写的"比"怎么写的"更该被项目管理追踪。
一个 40+ 模块的后台，如果核心知识只在 1-2 个人脑子里，
这本身就是比任何技术债都高的运营风险。数据目录
odts1/new-edsweb/
├── package.json
├── src/
│ ├── router/index.js → 40+ 路由配置
│ └── views/ → 29 个功能模块
└── 40+ feature branches