Appearance
最为开发工程师，最重要的一项能力，就是在问题出现之后以最快的速度去判断问题的责任归属，然后去解决或协助他人解决。但是在交付评估的发版前遇到的bug（其实也不算什么bug，只是大家不清楚原因）。没有准确的判定问题的方向，导致多浪费的近三个小时的时间。下面是关于问题的流水账和反思，按时间点来记录的。
需求 一线用户需要更新模版，但是他们还有季度评估的任务，所以只想更新交付评估模版。保留季度评估的模版和任务。
过程记录
- 前端增加模版更新的按钮，清除所有交付评估的数据库数据，点登陆时拉取最新的。
- 后端模版也改好，获取模版时就是新的模版。
- 测试验证，先切换旧模版，再去更新app（app版本有更新会自动删除旧模版，用户登录后就会去拉取接口获取最新的模版数据。
下面是bug的情景 验证时（App 更新到最新的版本，接口也替换成最新的模版，但是App端显示的还是旧模版，这时候去杀掉进程，就是最新的模版数据）
有时候杀掉进程不管用，还得清除缓存再杀掉进程。也是时好时坏（俊伯改好后有时App马上就会更新，有时却不会）
这时候有几种看法：
- 语轩：认为确实是缓存的问题。但是他倾向于后端把数据写入了App的缓存里。（这就解释了有时候杀掉进程是有效的）
- 书峰：它对杀掉进程会更新模版数据很不理解（认为前端的更新模版的方法出了问题，但是也只是猜测）但是有时后点击刷新模版进去就是好的。
- myself：我肯定我的刷新按钮是没有问题的，但是竟然也相信了后端会操作App内存的方法，也一时不知道原因在哪里。
上面就是大概的过程，导致我们竟然两个多小时去不断的杀进程，清数据，做这种无用功。作为评估组唯一的前端，没有起到相应的作用，找出原因。
正确的处理流程： 首先判断是不是接口的问题。这一步应该是最先做的，出现问题就去确认是否是这个原因。如果是接口返回的问题，OK，就算不是前端的锅了。或许还能给后端同事一点启发。 让后端同事继续排查问题。接下来就不管App的事了。
技术之路无止境。