解决问题时候的一些思考

总结一下今晚遇到的问题及其思考：
首先是 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