复盘：XSWT-1422 门店宝账号删除人员列表不刷新

jira号：http://jira.iguming.net:8080/browse/XSWT-1422

原因

账号管理的写接口是直接写在uuc，但是读接口是从门店宝读取，uuc的数据更新到门店宝需要一定时间，因此会出现延时情况。

分析过程

目前账号管理中，

写的接口大概有删除人员、删除店铺、配置权限、添加账号、添加店铺接口；

读的接口大概有查询用户/店铺列表，单人多店列表，单店多人列表，判断用户有无可添加店铺接口。

所以这些读的接口都会延迟。

解决方案

总的来说，解决方案就是调用查询接口成功后，隔一秒钟再次调用该接口，最多调用3次。

需要考虑的问题如下：

alt text

实际措施

编写公共定时器接口调用函数

export const recursion = (callback: () => Promise<boolean>) => {
  let cnt = 0;
  const setTimerForReq = () => {
    // 最多请求接口3次：reqUserList() 第1次，cnt= 0 第2次，cnt=1第3次
    if (cnt < 2)
      callback().then((updateFlag) => {
        setTimeout(() => {
          !updateFlag && setTimerForReq();
          cnt++;
        }, 1000);
      });
  };
  setTimerForReq();
};

在店铺管理页，调用用户列表接口的时候，递归调用接口recursion(reqUserList);
在用户管理页，调用店铺列表接口的时候，递归调用接口recursion(reqShopList);
更新标识：接口调用前，列表长度和当前接口调用返回数据的长度比较：

1 2	const updateFlag = temp.length !== userList.length; // 列表是否更新（只判断删除的更新）, userList的值为调接口前的值 return Promise.resolve(updateFlag);

隐藏缺陷

只解决了两个接口的延时问题，其他没有，例如顶部数字和按钮有无在删除店铺后没有更新

alt text

不删除、不添加，纯查看，接口就会调用3次
更新判断并不是严格，只是按照长度判断，不是按照具体内容判断

反思

为什么一开始没明白问题在哪

当天讨论的时候，我有个需求评审，导致错过了，不知道具体方案
具体方案是从简可、叶葳那里得知了
听到他们的方案后，没有做自己的思考，又陷入了不思考就执行的习惯误区

为什么没按时上线

这个问题是我负责，虽然是个线上问题，但是本身这个问题并不紧急，而且也没有我知道这个问题要4月3号上线
他们定的方案太过于简单了，我写程序的时候发现很多细节没考虑，导致写完就已经要下班了，忘记给测试说提测

3.什么解决方案

一开始讨论下来的方案是只解决删除人员的延迟问题：所以我只做了这个逻辑
给测试提测的时候，测试又说还有其他点，这次要一次性解决，比如添加账号、添加店铺、删除店铺：所以我又改了逻辑
把测试的想法给简可说了一下，简可、叶葳讨论下来说，只解决一些重点的接口，删除店铺和人员的接口：我按照这个又改了代码，但是发现添加店铺的时候，列表没有更新

经过这么一轮又一轮的修改后，而且最终问题也没有得到很好的解决，我开始重新思考整个过程。

本次问题的重点就是优化用户体验，让他在删除、添加的时候能看到最新的结果。
最差的情况下，接口调三次，服务也是可以承受的

所以最终的解决方案是本文的实际措施中的方案，我也把缺点写出来了。

最后，在解决这个线上问题的时候，我明白了一个很重要的道理，我应该要去主动弄清楚问题是什么，虽然我后端、服务器、数据库也不是很懂，但是毕竟我是负责人，我需要对结果负责，对结果负责的最好办法就是对问题原因、解决方案、实际措施、方案缺陷做到一清二楚。

我还不明白的问题

前后端都能实现的问题，前端做还是后端做有判断标准吗？
如果这个问题实现起来，逻辑很复杂，为什么前端实现就会变得没有价值，后端实现才有？

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。