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