解决问题时候的一些思考

总结一下今晚遇到的问题及其思考:
首先是 travis.ci 上的 ft 一直有 19个 case 没有跑过,看到异常信息里面有个 can not find endpoint to access 由于本地有时也会遇到这个问题,是由于ak不对,找不到 endpoint的问题。下意识地以为 ci 环境由于账号权限不够,找不到环境变量的 ak。
吃完饭,后来稍晚些时候,本地跑 ft 时发现怎么也有19个错误呢,这时没有把本地的错误和线上发生的错误联系起来。于是就去单步断点调试发现哪里有问题,先是手动设置endpoint ,发现 服务端 返回 400 错误,version 不正确。这时候能断定的一点就是确实是我的代码出现问题了。
接下来是排查本地代码的问题了,我查看了Github 上上次提交的代码的CI,是否成功运行,发现之前都是能成功运行的,问题锁定在今天提交的代码上,查看 PR 的 diff,终于在一个类的构造器初始化中发现了端倪。

具体是为什么其实已经不重要了,虽然这其实是个 很低级的错误,Setter 方法中不仅仅赋值。还添加到了 dict 中。然而我直接赋值给了 this.version 和 this.actionName 当然有问题。
其实发现这个问题,以及如何解决这个问题都是很简单,很简单的。

事后思考了一下,为什么如此简单的问题,自己会排查很久呢?

这整个排查过程至少有两个阶段我可以得出是我代码的问题。而不是权限不足的问题。
首先第一,我在 travis.ci 中配置了如果没有获取到 ak,则不跑 集成测试。然而现实情况是线上跑了一部分集成测试。
第二,在本地跑集成测试时发现错误后,发现和线上的错误数量case一样时,也应该想到。

为什么没有提早发现呢?
其一,先入为主的把之前的经验带入,进行判断。
其二,PR 的信息太乱了,没有遵循 一个PR,做一件事的思想。

获得到的经验以及自己的想法:
1,再一次验证了 把测试 回归起来的好处,可以验证自己写的代码到底有没有问题。
2,首先找自己的问题,有十足把握确定没问题了,再去检验别人的问题,给出你的观点和验证。
3,解决问题并不重要,重要的是知道为什么会出现这个问题,以及下次是否还会遇到这个问题。

具体 PR 的地址:https://github.com/aliyun/aliyun-openapi-net-sdk/compare/downward_compatible_csharp5_version

posted @ 2019-05-27 23:47  BUTTERAPPLE  阅读(87)  评论(0编辑  收藏