这是学习笔记的第 1960 篇文章
今天上午调试一个程序，中间磕磕绊绊，不过也有了不少感悟和总结。本来这个事情看起来是很简单的，是后端触发一个逻辑，然后触发即时通讯接口提醒，我预期是20分钟以内搞定，但是最后的时间尴尬了，花了快2个小时。
为什么这个事情一再延后呢，我们来复盘一下：
整个流程是这样的，后端逻辑需要把逻辑处理结果持久化存储到一张表里，同时触发异步任务，异步任务会去调用即时通讯接口，最终给予提醒。
我这边的进度是这样的：
10:10开始准备完善后端流程
因为逻辑中对于时间计算操作，于是临时又写了一个工具函数
10:30 勉强完成了逻辑的开发，还没有开始测试
然后开始测试的时候，本来是要在本地测试环境测试的，但是限于异步队列的环境和测试数据的差异，就直接在线上环境测试了，这其实是一个很不好的习惯。
本来以为这个过程会很轻松，但是发现了一系列问题：
1）数据表中没有记录
2）没有生成异步任务
3）没有调用即时通讯接口
一个不是很明朗的问题，如果同时碰到了这些问题，排查起来是有一定复杂度的。
所以开始的时候是在程序逻辑上检查，经过几次线上测试，重新发布，总算是定位到了问题的初步方向，原来是时间计算逻辑反了。
继续调试
1）发现一个程序语言的功能使用错误
2）字符串里面的日期类型和字符串类型不兼容，需要特意转换
前后忙忙碌碌了好一会，还是没有任何数据生成，也没有异步任务生成。
最后加了更细粒度的日志，发现原来是通讯接口的参数调用上有问题，因为最后一步失败了，所以前面的步骤都没有顺利执行。
在这个过程中，自己都有些怀疑自己的能力了。
在调试之后，不下十多次的反反复复发布，总算定位了问题，做了修复。
在这个过程中，自己也感触很深，最后的问题解决，主要是因为我在测试环境重新配置了任务队列，完整模拟了问题的过程，逐步定位才找到的，所以测试环境中的测试还是很重要的，自己感觉没有问题的地方，其实还不具备交付条件，交付一定是一种完全可控的流程，要不里面的其他逻辑都很好，但是就是临门一脚出了问题，很吃亏的。
同时自己也做了深刻的思考，这个问题修复之后，我对已有的工作安排做了下筛查，发现还有一个需求是和这个提醒相关的，第2个功能做起来就快得多了，轻车熟路，所以我们的工作也是有一定的关联性的，尽可能在一些有关联熟悉的环境间跳转，避免出现较大的差异，导致工作效率低下。
相关链接：