Spring项目参数转换失败
产品测试项目中投递岗位，提示“参数转换失败”，错误信息前端没有匹配的，后端异常信息记录不全。用户的简历也不知道怎么删，项目中有多种缓存。加上前面几天有紧急需求要处理。星期一早上提的问题，过了四天，才在老板提醒下处理，并与下个周一处理完。
过程
周一早上在测试处理各种问题，产品提了一个不好复现的问题（已经有简历的无法复现），bug中描述的返回是点小程序左上角的箭头。下午又有紧急需求出现，要周四发版。周四有数据分析需求要给结果。实际给到处理问题的时间比较少，并且是效率最低的周五。一开始定位是异常信息返回不全，具体的异常也不是java异常体系的，实际记录的异常指定了关键信息，但是也不全。问题不好复现，因为前后端开发都已经建过简历。后端实际调的远程服务，远程服务没有给删除简历的接口，没有找老板帮忙删数据，然后想办法在那模拟删除简历，最后让同事帮忙验证，已经到下班时间，同事下班。我自己在那模拟数据，增加清理缓存的接口。
在周六休息一天，效率变高后，周日到公司加了一个小时的班，准备结合以往经验，仔细看代码逻辑，从代码入手。发现记录了异常日志，可以搜索，提高了搜索效率。也查了对应异常的资料，发现是Spring中的异常，是由前端传参undefined导致，但是框架没封装好，没记录详细的异常信息。大致理清问题后，下班了。
今天周一提前一个多小时来上班，与前端沟通后，告诉了前端问题和解决方案，前端还是想要先清理简历。找老板帮忙无果，于是找运维帮忙，运维给的数据库不对。在查看RPCenter的项目源码后，自己确定了RPCenter测试环境使用的数据库，并从redis缓存、RPCenter数据、本地数据库中清除数据，配合测试。前端解决后发二维码给我扫，我没发现问题，找同事看，同事没发现问题。于是改了bug状态，让产品验证。
耗时：7个小时+2小时通勤。预计耗时：1小时
问题
- 产品提的问题优先级被我设置的比较低，要低于要发布的绩效改版。但是老板实际定的优先级比较高。如果有bug，优先处理bug。
- 对Spring 的异常体系结构不了解。
- 没有仔细看代码，虽然返回的异常信息不全，但是记录的异常信息稍微全一点。
- 缝状的框架有问题，异常处理过于统一，但是不实用。
- 全局异常处理在业务模块和框架模块重复封装了。完善异常日志时，发现改的不生效。
- 不知道如何删除rpcenter数据库中的简历。已经有官网代码了，但是因为没人教，就没删。后面找运维结合自己找代码就删除成功了。
- 周日把电脑带回家，发现在家不能访问公有云数据库，只能等到周一到公司，连公司网。浪费了坐车的两个多小时。
- 模拟删除简历一直失败，对前端怎么使用接口、使用哪些接口不了解，浪费了很多时间。
值得肯定的地方
- 在找不到问题突破口的时候，还是以认真看代码、直接从具体异常的资料作为入口，加上阅读spring源码，最终定位到问题是控制器方法无法解析参数导致的问题，并且搜索到了对应日志，让前端愿意相信问题在哪
- 周五效率低，等周六休息一天后，周日一个小时就定位到了问题。
- 周五加班，刚好老板晚上九点多提了生产的几个问题，可以处理
总结
- 要了解Spring的异常体系结构和各种异常的发生时机、位置、原因，以及对应解决方案
- 要仔细阅读代码，返回的异常信息不等于记录的异常日志
- 不要陷入一种解决方案中，比如这次使用的数据模拟
- 周五效率低，可以等周六休息后，周日效率高了再处理
- 公有云数据库的访问都是从phpAdmin中访问，每次要指定ip和端口
- 自己有远程服务的项目源码，就不要嫌麻烦，看下源码，即使语言不熟悉
- 多级缓存不方便调试，要想办法添加一键清除缓存
改进措施
- 了解Spring异常体系结构
- 大致了解rpcenter的项目的功能
- 处理bug时，要认真、慢慢看源码，不能为了省几分钟，导致后续浪费几个小时
- 涉及到公有云相关的问题，尽量在公司处理。服务对ip限制比较严
- 难的问题，就不要留在周五处理。前面已经连续加了四天班
- 可以周三适当早点下班、或者去运动，避免周五效率低
实施计划
- 周三尽量早点下班，提高周四、周五的工作效率
- 熟悉Spring的异常体系结构，尽量可视化，列表格
- 了解rpcenter的数据库设计、基本接口，即使不负责该项目
