昵称登录后显示

## 经验一、部门 Web端技术建设：

角色：负责团队 Web端规范 + 基础建设，并推动业务线接入

背景：
- 团队大（前端团队约为 30人左右）；
- 基础建设缺失（团队缺少基础建设、规范、约束等行为）；
- UI 组件库升级风险高；
- 项目交互、技术栈较为统一（部门主要维护项目为药店 SaaS系统）；
- 无任何基础组件、Layout组件沉淀；
- UI bug 反复出现；
- 缺少接口 mock服务；
- 联调环节效率低下；

行动：
- 基于 `Element-ui` 搭建部门组件库（主 R + 规划、主要开发、迭代人）；
- 统一部门 `eslint` 规则发布到 xnpm平台，并提供 VSCode 保存文件自动格式化能力；
- 完成验证、工具库等落地与项目接入（非主要开发，项目发起人+推动组内成员完成）；
- 编写、推动部门前后端接口交互文档标准；
- 推动集团基于 `yapi` 部署统一接口 mock平台；

难点：
- 前端基础建设从无到有，更加注重项目优先级，收益最大化；
- 团队成员开发能力以及认知差异较大；

结果：
- UI组件库较为可控升级，且无线上事故发生；
- 提升团队代码开发质量，日均 bug率平均降低到 3以下；
- 提升联调效率；

## 经验二、供应链系统架构演进（2018年底）：

美团 - 供应链系统架构演进（2018年底）

#### 一、微前端多系统整合

角色：项目主R（1人） + 推动业务侧研发接入
背景：
- 供应链系统中 10+业务模块在独立仓库中维护、部署；
- 技术栈不统一：业务组用 Vue，数据组用 React；

问题：
- 迭代：公共部分（类似菜单改版、添加面包屑、公共服务类需求）升级成本高（代码改动 10+工程）、上线风险大（上线 10+工程）；
- 体验较差：页面相互独立，菜单切换刷新页面；

行动：
- 进行主/子系统拆分。主系统提供公共类服务（菜单、搜索、面包屑、反馈等）；子系统为业务系统，负责具体业务逻辑，通过 iframe整合主子系统。

难点：
- 线上 URL不能改变，保证培训教程/用户书签可用；
- 业务系统迭代方式与之前尽量保持一致；
- 引入 iframe之后带来新的 UI层问题解决：Dialog弹窗类、UI消息类问题；

结果：
- 任务完成，问题解决；
- 改造之后与之前体验基本保持一致，没有 UI、交互上的倒退，上线后用户无体验类问题反馈。切换菜单体验更加友好；
- 降低公共模块迭代成本，提升效率；