T上西北

杰出产品的一丝遗憾:微信

时至今日,恐怕谁也无法否认,微信是一个非常杰出的产品,看看现在有多少活跃用户就知道了。因为它,人们对腾讯有了无线的遐想和成长空间,这也让腾讯的市值在一年间翻倍还多,同时也给出足够高的市盈率。我在想,若不是微信,腾讯现在是一种什么样的情况,现在BAT三足鼎立竞争不会这么激烈吧?

关于微信的无限遐想还有N多,balalala,恐怕一天都写不完。

但是今天,我之所以写本文,是在这个伟大产品背后看到了一丝遗憾的东西,那就是微信工作平台的接入API和文档,尽管它们还不足以成为大问题,但的确让我看到了一丝隐忧。

几个月前,我有机会试了一下公众平台的API,令我吃惊的是,我发现这些API和文档真的写的太一般,让我无法想象这是出自于腾讯之手。看了这些文档后,我对于一些问题根本不知道如何下手。幸好API还算简单,否则真是搞死一帮人。

遗憾之一:非常一般的文档

个人认为,一篇好的文档必须从用户的角度去思考,能解决一般问题,再做更好的话,是可以解决一些疑难症状。总之,文档是用来给用户解决问题的。我试着问几个问题:

请问微信和自己开发的服务是一个什么样的关系?什么样的架构?翻了一通文档,死也没找见。一上来就是如何接入,关键是接入的文档也没把原理写清楚。我想每个开发人员都想了解系统框架和接入原理吧。这样就可以在宏观上把握整个系统。
在处理消息时,我当时就在想,用户在微信发出一个消息时,server端如何知道这个消息并处理和返回?这些原理有吗?没有!整个很重要,可以了解到完整的消息流程。
在创建自定义菜单时,我真的非常迷惑,微信的app到底是怎么自定义菜单的呢?是主动还被动?总之,我得不到想要的答案。最后根据文档发现(或者说是猜想),需要自己主动POST数据。结合别人写的代码才能验证我的想法。
代码写好后,开始调试。文档里是提供在线调试的。但是对于有些调试(尤其是处理message)来说,有时候真的不知道怎么传参数,反而把人搞得非常confuse。
细节也是注意不够,例如参数的定义和说明,有些真没说清楚,这样会让大家浪费很多时间。

上面提到的都是文档中出现的几个主要问题。如果满分是100分的话,那这文档也就是30分左右,离一份优秀的文档差远了。

分析一下写文档的人:

或是说,总以为每个开发者都跟微信API的开发者一样,精通微信的原理。
或是说,总以为开发者肯定都是不错的开发者,有些问题能搞明白。
或是说,这些写文档的人根本不知道如何写文档。或者说根本不知道开发者想要什么。
或是说,写文档的人根本不知道如何写好一篇文档。
不得不说,写文档是一件比写代码还要难的事情,从我们生活周围发现,代码噼噼啪啪写完,很快。一旦涉及到写文档,就犯难。但是,如果写API的文档,就必须写好,尤其是这么重要平台的产品。

写文档不需要假设,因为自身知识的欠缺,如果有假设行为,会导致文档写的有缺陷。

遗憾二:API接口一塌糊涂

不得不说,这是我见过一些伟大平台API写的最糟糕的,对,没有之一。从侧面也反映了我们国内程序员写API的能力非常一般。

大小写不一致

OK,看看发送图文消息的接口:




12345678

2

<![CDATA[title1]]>





<![CDATA[title]]>






乍一看真没什么问题,但其实这里有一个非常不恰当的做法,为什么item的i变成小写了,这个其他element不一致,这也是容易出问题的地方。因为按照大家写代码的习惯,总以为这些名字的大小写是一致的。最后发现自己死也调不通,收到的是格式错误的错误信息。费了半天劲,才发现这里错了,于是心里面默默的把腾讯骂了一通。我想信这样的case不在少数。

让我们继续看看下面的API,

http请求方式: POST
https://api.weixin.qq.com/cgi-bin/message/custom/send?access_token=ACCESS_TOKEN
我不否认这个API不对,但是绝对不是最合理的地方,access_token怎么就加到了URL里,还是POST。足可以看出api设计的不严谨。

数据格式不一致

有时用XML格式传输数据,有时用JSON,我想说的是,能否把这些统一起来。设计api的人脑子是坏掉了吗?或者要么在前面所,我们既支持JSON又支持XML。现在好了,不伦不类的。

命名不一致

看看下面的实例,我们可以了解到element命名不统一的问题:

{
“”:”OPENID”,
“msgtype”:”video”,
“video”:
{
“”:”MEDIA_ID”,
“title”:”TITLE”,
“description”:”DESCRIPTION”
}
}
看到了吧,media_id中间有下划线,但是touser中间没有。咱们再看看下面的


<>

1348831860


1234567890123456

同时是toUser,怎么2个地方命名不一致呢。

总之,写到这里,我彻底被征服了,这种彻底被打败的感觉令人压抑。要不是为了让微信平台的打通,早就放弃了。感觉这api的定义没有整体规划,写到哪算哪的意思。

API是最能掩饰开发者的无能,因为只有接口暴露给人家。举个不恰当的例子,林志玲看起来够完美吧,谁知道她身上是否有伤疤,皮肤不够细腻呢(我倒是想验证一下, :))?所以,无论背后逻辑写的多烂,但怎么着也得把接口整得漂亮点吧。

遗憾三: 安全性

我发现一个严重的问题,简单描述一下,能看懂的就看,看不懂的就算了。问题的描述如下:

如果有多个app(至少2个)都启用了开发者功能,而且这几个app对应不同的公共账号,但是这几个app后台对应完全相同的代码,这就意味着自定义菜单和菜单的action都一样。问题来了,你会发现这些菜单的action其实和token,appid没太大关系,都可以使用,而且结果都一样。

以上问题不能说得太清楚了,否则整个app行为就会混乱的问题。

通过这个漏洞,我真的非常担心微信的安全性问题。当然咱也不清楚是人家故意这么做的,还是系统真的留下了这么一个大彩蛋。

从以上一系列的问题,我们可以看到,这个后台完全是没有章法,一是反映出微信团队管理的问题,二是开发者的问题。无论微信多么漂亮专业,但是通过这些后台的东西,足可以看出存在的问题。

说的严重一些,是不是整个微信团队,无论是前台还是后端,都存在相同问题。希望这仅是个案,而不是普遍。我有点悲观,我估计是后者的可能性较大。

另外,有人说进腾讯很难,是啊,是很难。但是并不意味着腾讯的人个个人都很牛B(当然也有很多牛B的人)。从今天写的几个问题就可以看出。

你说呢?

–关注我的微信公众账号–
您觉得这篇文章对您有帮助,可以订阅我的公众账号。查找”Terry说道” 或”terrysaid“

1个评论

  1. MatheMatrix says:

    恩 图貌似挂掉了