项目复盘梳理-04-客诉流程 工单状态流转 页面内嵌
客诉
背景
客户可能会提起投诉。
以前都是通过邮件 + EXCEL的方式，不利于分析与流转。
整体功能
内控上传工单
1）首先进行工单的信息校验，判断是否合法，是否重复等等，把校验不通过的返回给页面。
PS：这个步骤是比较漫长的，不要让用户同步等待，而是后端异步处理。最后让运营可以再内控文件下载中心查看。
2）后端程序调用商户+服务商服务，把数据全部填充完成。状态初始化为 I
3）内控可以看到所有的工单，可以对工单进行审核/或者修改。
4）外控服务商，可以看到自己名下的单子。所有的流转日志，处理对应的工单信息，上传对应的材料等信息。
工单可能存在超时等。
页面嵌套方式
这个页面是内嵌在已经的控台中的页面。
内嵌的方式有多种：
1）直接 iframe 内嵌，这个存在一定的缓存。虽然简单，但是不利于拓展。
2）基于乾坤这种微服务。
开始是基于 iframe 内嵌的，后续改成了基于基于乾坤的。
鉴权流程
页面进入时，首先获取内嵌容器中的 token，然后携带给后端。进行初次的鉴权。
1）第一次鉴权比较慢，需要获取对应的菜单权限等信息。并返回新的 newToken
为了前端好处理，把按钮权限进行了一些摊平，简化。
2）后续其他请求，携带的是 newToken。
newToken 一个作用是校验合法性，另一个是因为登录等功能不在我这边。
所以需要每次验证一下 newToken 对应的信息是否有效。如果无效，则报错。
提示用户重新登录。
一些收获
【需求层面】
不紧急的需求：
（1）页面的误操作校验
xx号：只能输入数字/字母
xx名：只能输入中文
时间不多时，不应该接
（2）框架层面
要求滚动条固定等，需要修改前端框架才可能实现的，不接受。
原因：
ROI 太低，把时间浪费在无关紧要的地方，会导致精力分散，无法专注于实现功能。
【需求变更+实现】
需求在实现过程中，经常会发生变更。
后端接口也是类似的。
（1）要注意和产品确认最新的文档。产品修改通知开发+测试;
（2）让界面符合产品的要求/审美，比如输入框显的很高，缺少分隔线等
上线前测试环境让产品先过一遍。
【需求测试】
问：为什么会犯这么低级的错误？如页面少了一个字段。
原因：
（1）需求文档和项目原型不一致，修改需求时前端+测试不知道。
（2）测试时间较短，未能全面覆盖。
【技术的优缺点】
页面内嵌，让后端鉴权+前端页面变得都比以前复杂。
乾坤和IFRAME都有优缺点（坑），不过微服务是方向。
【底层依赖的问题】
（1）API 网关存在BUG
（2）流水线故障，无法发布
（3）HOC 发布存在 BUG
（4）HOLMES测试覆盖率存在问题
协查
说明
整体流程和客诉很类似。
唯一的差异比较大的地方，就是文件比较复杂，全部是动态的。
不同的类别，需要不同的文件提供证明信息。
所以全部设计为后端动态返回。
复盘
文件上传问题
视频等文件，要求 30M
超过 10MB 的文件，jboss 会报错。询问配管，没人遇到过，说明以前没有超过 10MB 的文件实际上传需求。
耗时问题。针对外控的多个上传文件，内控/风控要求统一的压缩包。
10MB + 10MB + 20MB = 40MB
会导致压缩包很大，上传很慢。
较大的文件，导致文件解析的耗时。
用户体验很差，所以调整为异步。
联调时间约定
商户信息：后端 + 商户前置
后端与风控：jar 包提供的较晚。
需要约定好联调日期，接口提供日期。
约定好联调开始+结束日期。
页面样式
尽可能保证页面风格和已有的系统保持一致。