Apart：
逻辑的复杂 => 用户使用的复杂 + 运维的复杂
业务（简单 -> 复杂）（技术跟不上业务的变化）
架构升级 （对业务的再建模）
业务好用
架构简单
or else 用户也会得到复杂的东西
Bpart：
另起炉灶
adapter稳住 + 外科手术（分步）
magical + （工程基础：vue-lib,template, lib(core_sdk + basics_ui) + service（topic + pdf_template））
我还是不知道你要什么，我自己分层，抽能力，抽核心，基础建设+基础碎片=>业务需求组合
Cpart:
自建 + 服务购入（快速构建，服务带来限制）
通用问题的解决，和现有体系的打通
edas对比图表(https://www.aliyun.com/product/edas?spm=5176.13910061.746114.1.5b51295eWIu9uZ)
Dpart:
业务，产品，技术
目标，考核指标，后续迭代的评价规则
Cases
登录和权限一定要理清楚
- 看了下别的团队的一个复盘，描述了问题，但是不彻底
- 我们都会接入XX统一登录中心，进行验证，是否有XX身份的权限
- A团队的问题是，对于子系统的权限，和是否具有XX身份的权限处理不明确，从而导致了再统一登录页面陷入了逻辑循环
- Chrome浏览器和非Chrome浏览器等会有各个因为安全的配置，不同的版本，导致的对cookie的处理的不同差异，做有关后台写入cookie的问题的时候，一定要注意到这点
针对浏览器兼容性的问题
- 定位要准确
- 做好运营（landing）页面，浏览器的下载引导
- 系统拉横幅，针对兼容性差的IE等收集来的信息，直接进行判断，显示下载提示和按钮
- 做好前端行为的上报，这样可以在服务端接口没有trace的时候，通过手机号，时间等信息，trace到用户的设备
