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