周末用了下新浪微博開放平臺API和官方發布的Java客戶端，感覺可以用兩個字形容：坑爹！
先說說遇到的幾個極其弱智的bug吧：
1）分頁
官方API文檔里面對數據分頁獲取的說明是使用cursor和count這兩個參數。其中，cursor指明了起始記錄的位置，而count指明了當前每頁的記錄條數，請求第一頁的時候cursor為-1。返回結果會給出next_cursor，指明下一頁的起始位置。
這個設計看起來不錯，問題是根據這個文檔，得到的結果會有重復。也就是說同一條記錄會出現在多個頁面中，而且這種重復出現的頻率是隨機的。試想連程序的行為都無法預測，叫別人怎么開發應用？！
更搞笑的是，官方發布的Java客戶端居然把cursor寫成了page，導致了不管怎么設置參數，返回的都是很多重復的數據，但重復的比例又是隨機的！難道新浪沒有對這個客戶端進行過簡單的測試就發布了嗎？無法想象！！
2）返回結果的解析
好不容易把用戶信息得到了，新浪自己寫了一個JavaBean用來表示一個User的信息。問題是把JSON解析成Java對象的時候，居然把布爾屬性字段解析錯了，導致每次返回都是false，好不容易得到的數據就這么泡湯了~~難道解析JSON很難嘛？？敢測試下再發布嗎？
3）詭異的負數
我小學學到的知識告訴我，人的個數不可能是負數。于是我天真的在followers_count這個數據庫字段上加了unsigned，本以為教數據庫的老師應該很開心吧，這孩子設計的數據庫還蠻嚴謹的，而且應該能夠和新浪的數據很好地匹配。
于是我開心的運行程序，詭異的錯誤出現了：超出字段范圍。暈，于是檢查所有數字字段是否超過了表示范圍，N遍檢查過后確認數據庫沒問題，糾結~~于是看log，發現返回的數據里面，有一個項的followers_cout字段是-2，負數！！！尼瑪這人雖然粉絲少了點，也不至于欠你新浪兩個粉絲吧，我當時就凌亂了，于是加了很多異常數據的判斷和檢查。。。
4）詭異的版權信息
Java客戶端里面很多文件的作者信息是：@author Yusuke Yamamoto - yusuke at mac.com，感覺這應該是一個蘋果公司的員工開發的，然后新浪拿過來，沒有code review，沒有測試，就直接官方發布了。。。
這樣不重視代碼質量，把產品構建在志愿者的貢獻之上，我覺得是新浪的恥辱，更是中國互聯網產業的頑癥惡疾。
以上只是我這兩天試用了一小部分API的感受。由于各種bug，我不得不閱讀源代碼，并根據我的需求改寫代碼，甚至一度我準備拋棄這個客戶端，直接用HTTP調用。反正最后嚴重降低了我的效率。
回想起這兩天傳高鐵出事是程序員的問題，我看要按照新浪這質量標準，不知道還要出什么大事~~