问题经过
UAT测试反馈该问题，提了tapd的bug
问题处理过程
体验有招小程序后，发现的确可以重复投递，参考 tapd bug 上的描述，准备参考官网实现功能。
详细过程
| 子过程 | 具体描述 | 耗时 |
|---|---|---|
| 官网系统处理过程 | 拉代码-》找领导申请权限-》拉代码-》找代码-》联想到gaia | 花费一个半小时 |
| 有招小程序处理过程 | 新增service、找申请记录表、单元测试、找产品要UI效果 | 花费两个小时。 |
| 转折 | 经和前端沟通，发现原来有该功能，UAT测试时突然没有了，于是把经历花在找后端bug上 | 半小时 |
| 找bug | 通过看代码逻辑，判断是检查逻辑的传参问题，但是对简历不熟，以为不同参数具有同样意义，就加各种测试日志，发不到测试环境测试，最终定位到问题就是传参的问题 | 耗时两个多小时。 |
处理流程分析：
- 一开始没有定位tapd问题类型是新增功能还是修改bug，绕了一大圈，如果原来就有改功能就是bug。
- 定位了bug后，的确按照先看完整代码逻辑，然后定位问题的步骤处理了。一开始就锁定了传参，但因为对简历不够了解，于是加调试日志，又花了很多时间。代码没看完整，没看写申请记录用的是哪个字段，被数据库里数据带偏（没验证数据正确性）。
总结：
- 问题要进行类型分析：新增、bug，要问别人原来是否有这功能
- 处理bug，要耐心把代码看完整
- 不要完全相信测试环境的数据，有可能数据是人为造的，错的数据
- 对原有系统功能的细节不熟，可以详细分析接口的功能
预计提效
从五个半小时缩短到半个小时。提效11倍。
