工作记录2022-

最近工作出了很多问题，大部分是自己的问题。

按时间从后往前说。

===========问题分隔线=============

第一个问题

昨天下午联调时发现镜像环境函数接口响应是失败的，然后打电话问，查日志后说是函数那边做兼容的代码有问题。报的那个错其实我周一的时候就发现了，当时做了个啥操作呢？当时在处理另一个问题，看数据库里函数接口响应日志不对，第一时间以为是接口问题，然后本地启动服务，调了下，本地响应是好的，然后就潜意识以为是数据问题，但又没想数据有什么问题，然后把问题抛下了。

当时处理的有问题，镜像环境出了问题，要把问题定位清楚解决问题，只从本地验证了下本地正常并不表示镜像是正常的。问题应该这样定位，处理问题前先搞清楚几个事，在什么环境？接口地址是否正确？自己做过什么改动？接口方做过什么改动？数据是否有问题？

现在来回答下。镜像环境出的问题；镜像环境和ST环境调的接口地址是相同的；自己没做过改动（当时测ST环境时改过数据库）；接口方做了兼容代码（这个当时没想到）；数据有问题（当时没想到）。当时没想到后边两个原因是因为本地测试通过后就认为没问题了，把镜像环境问题放下了，导致挖了个坑。后来发现时，函数都要上线了，多方沟通后，在新版本上线后，我们把镜像环境数据改一下。这样改的好处是大家不用改代码了，不用之后再为了处理现在的兼容代码再改代码上线。

这个问题收到的教训是环境上出问题后一定要把问题真正解决才算。解决的思路，先搞清楚几个事，在什么环境？接口地址是否正确？自己做过什么改动？接口方做过什么改动？数据是否有问题？搞清楚这些问题后，还是解决不了，从更高的层面考虑程序执行顺序的影响，多线程的影响，把环境数据拿到本地断点调试。

这个问题还发现一个问题，函数部署成功后，页面上查询已部署的函数无数据。定位后发现，部署时调的函数ST环境接口，页面上对接的是函数镜像环境接口所以页面上查不到。然后这就完了吗？我看就完了，然后德哥提出函数要提供一个镜像环境的部署接口地址，这样，部署完后就能在页面上查到了，这才是把问题处理完。

===========问题分隔线=============

第二个问题也是之前埋的一个坑，导致德哥查了一上午的时间。

因为这次模板服务是调用外部接口整体变了，流程也改了。外部接口方会先上线，这边使用一个开关来控制调用旧接口还是新接口。这个是背景，开始联调新接口时，需要设置认证密钥，我当时把调旧接口的密钥改了，这样是错的，然后又加了新接口的密钥配置，然而并没有把旧接口的密钥还原回去。所以这里又挖了一个坑。

当时是怎么想的呢。当时就是乌龟式的想法，首先是想到了把旧密钥还原，然后，发现没有密钥明文，只有密文，尝试用一种方法解密，不成功，然后就想着，别人应该会改回去（不要脸了），然后就没管。

这里处理的问题是，首先，其实通过打断点方式是可以拿到密文的，第二，没有密文问别人要。也要把配置还原，不然后边就是坑，填坑浪费的时间远比当时处理要多的多。

===========问题分隔线=============

第三个问题，还是之前挖的坑，真是平平无奇挖坑能手。

有一个需求，需求文档里写的不清楚，需求讲解时也没说清楚，需要我下来找人确认。因为对业务页面操作不熟悉，就一直放着不处理。问题放着不处理它并不会消失，TMD，它会膨胀为更大的问题，操。

前天拉着测试电话说了下，拉了几个人，终于把问题搞清楚了，也就是，页面弹出了需求里描述的问题现象，然后，还是德哥给了解决方法。

这个问题的根本原因是问题放着不处理它并不会消失。所以，不要不处理问题。

===========问题分隔线=============

第四个问题，是开发时需求不理解透彻引起的。

有一个需求是要调外部一个接口，接口有多个入参，其中一个是非必传入参，然后这个入参传 null　会报错，传空字符串不会报错。导致后来页面功能不能用４个小时，很僵硬。

这个问题是测试不到位。

现在能想到的就是这几个问题，其实还有几个小问题，比如，改代码时把多个并关系的 if 判断分成两个 if 判断，这TM 的不是傻吗。

==============总结===============

总结一下，工作中要关注需求分析、开发、自测、联调测、送测、上线。有些环节需要提前准备一些资源，比如联调地址、熟悉业务场景，出了问题遵从程序运行的环境、运行逻辑、断点等方式考虑。