2020-03-10

先用新冠时期流行的一句话来开始 --- ”时代的一粒灰，落在个人头上，就是一座山“。出自著名作家方方。

最近生活作息基本上回到工作时的状态了，每天能在零点前睡觉，早上在 8 点前起床，一日三餐能保证在合理时间内完成。但在工作上有一些不足，需要反思一下。

最近工作任务比较多，有三个功能都是新开发，要从分析需求开始，写代码，自己测试，放到测试环境测试，测试人员测试，上线，一步步进行。工作任务多了，才发现技术积累的少了，有的需求分析不到位，一些关键的点没有考虑到，比如在分析电子批单，电子条款下载需求时，了解了业务流程，从哪个接口返回报文中取字段作为此次需求流程的入口，看了那个接口响应报文，了解了需求有几个页面，每个页面大概要开发几个接口。分析完这些后，就说需求审核完了，其实还有重要的一块---调核心接口请求字段能不能全部提供，响应字段（数据）能不能满足页面需求。这部分是审核最重要的反而没评审到。这是第一个不足。

第二个不足是开发ecifid替换五要素功能时，业务流程很简单：1，五要素查询用户信息，检查用户是否绑定保单；2，绑定保单的用户，调ecif系统接口查询ecifid;3，查回来的ecifid判断如果用户已经有ecifid，检查是否需要更新，没有则插表；4，最后返回给前端ecifid；5，基于一个基本流程添加一些便于其他工程调用的入口，比如，拿用户手机号来查。开发的时候没有这样想过，导致开发的时候思维处于比较乱的状态，哪些做了，哪些没做，需要通过一次次的测试来发现问题，修复问题，而不是提前规划好。还有就是代码写完后要检查流程逻辑有没有短缺的，前两天就发现，从数据库查ecifid的方法流程有短缺的，查出来的数据没有放到返回对象里，导致程序报了空指针。而且这块代码已经上线了。这样真的不行。

第三个不足是技术积累不足。两件事，第一个是integration工程里有一个常量直接用ResourceBundle取属性文件中的属性初始化，类似：private static final String cancel = bundle.getString("cancelKey");，然后在类方法中直接使用 cancel 变量，然后把 integration 工程maven打包，install 到仓库，当 user 工程调 integration 工程中的方法时，报了空指针。其实这个是最后定位到的问题，最开始是发现日志中没有打出方法中的日志，看代码方法是在一个新启动的线程里执行，但日志用 traceSpan 设置了线程 traceid 跟父线程一致了。大量的时间浪费在定位 integration 中的方法有没有调用上，因为看不到日志，最后检查发现日志没打印是因为日志工厂类用的是 slf4j 的 LoggerFactory 而不是工程自己的 DAPTraceLoggerFactory，改了后能够打印日志，进而发现上边的空指针问题。这里要吸取的是一个问题一个问题处理，既然没有日志，检查日志相关代码，一般就两处，一处线程有没有使用父线程 traceid，另一处就是使用的 LoggerFactory 是否正确。在这个问题上浪费了整整两天时间，不该。第二个是今天跟前端有关的一个问题，从微信公众号跳到浏览器下载一个 PDF 文件，安卓手机和电脑浏览器上可以下载，但在IOS手机上报错”error on line 1 at column 1: Document is empty error on line 1 at column 1: Encoding error“，前端说是后端的问题，然后调查了一下午，晚上 8 点多直接把下载链接放到IOS浏览器发现是可以下载的，那应该是微信调起浏览器时出现的问题。早点这样定位就好了。

还有一些其他缺点，比如，花了很长时间定位到问题，本该接着验证假设了，这时候做其他的了。军事上讲乘胜追击，这个习惯得改，定位后马上验证，直到问题解决。

最后记一点，以后要养成记日记的习惯，不能以没有时间作为借口。从今天起记日记，坚持！