周末用了下新浪微博开放平台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调用。反正最后严重降低了我的效率。
回想起这两天传高铁出事是程序员的问题，我看要按照新浪这质量标准，不知道还要出什么大事~~