解決問題時候的一些思考

總結一下今晚遇到的問題及其思考：
首先是 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