微信应用框架CSDN采访

for @xiamz

请您先自我介绍下

盛保善 // 长居北京的数位产品设计师

• 2014年8月起，我将全时投入在一个古典音乐应用的设计与工程上；
• 2013年，为专业医疗机构瀚思维康设计基于Mongoose的文档式医疗数据标准，内部交付了8个高度现代化的专业医疗Windows商店应用；
• 2012年，作为创新顾问，设计国内首家医疗卫生评估企业核心业务，服务中南大学湘雅医院等多家医院；
• 2011年，共同发明了利用射频对等网络作为异构传输层，扩展手机蓝牙距离的智能家居系统方案（发明专利CN102221830B）；
• 2010年，作为惠斯康健康科技（北京）有限公司的Entrepreneur-in-Residence，设计企业移动互联网战略；
• 2008至9年，联合创立了国际古典音乐数据库，在美国哥伦比亚特区注册，开展音乐学研究和小规模的古典音乐编目活动；
• 拥有清华大学电子工程系工学学士学位、清华大学软件学院软件工程硕士学位。

CSDN是开发者社区，是中国的HN吧！向骇客同行们快速介绍我的专业技能：我GitHub账号@baoshan，常用邮箱：sheng@icmd.org，我是：

• 应用层电子工程师（Atmel MC、RF/Bluetooth、Arduino）
• RDBMS的DBA（T-SQL）
• 应用开发者（CoffeeScript、Ruby、C#）
• UX设计师
• UI设计师（Sketch）
• 再加上你采访的角色————框架设计师

公司团队

我服务过的公司都是初创规模（职业经历和技能都能推断得出吧），我直接管理的团队规模在10人以下。

微信应用框架由我设计并完成npm模组，做演示网站时（weixinjs.org）另有4名同事参与了界面、内容等重要工作。

如何想到要开发微信应用框架

4月底，我的同学说了个创意，觉得能够吸引很多用户，但我对微信（和一切泛Social的东西）没兴趣。我不信，后来证明我错了。我做了个仅有一个按钮的微信服务号，不推广、无分享，现在有北京6万多的实名注册医生用户，这是一个奇迹。

期间有没有遇到一些难点

微信应用框架属于游戏级别的项目，属于1个人1周的工作量，所遇到的难点都是对自己的质疑：

• 设计是否达到极简主义的标准？
• 哪样暴露接口，更能向应用级工程师的业务语言靠拢，达到文学化编程的最终境地？
• ......

话说回来，最大的难点在以后。我想到了几个很棒的设计改进点，可惜没有时间完善了。

“微信应用框架”是款什么样的产品

“微信应用框架”是极简设计的微信（公共平台）应用参考级框架，而并非微信接口在node.js下的幂等映射。

什么是幂等映射的微信SDK？将微信的每个HTTP接口（不是REST接口，没关系，这不是重点），在对应的运行时下起个名字，将HTTP接口的参数映射成函数签名参数，这样的微信SDK，称为幂等映射的微信SDK。遗憾的是，流行的几个微信SDK不少是这样的。直接诊断标准就是：腾讯的API怎么分类，它的SDK接口就怎么分类；腾讯API有几个，它的SDK就有几个。

等等，你说应用框架是一种产品，太好了。Framework、Library、Tooklit、计算机语言等等都是产品，好的产品具备哪些特点呢？

• 好产品服务好客户，好的产品经理从不跟用户斗争，在大多数技术落伍的传统领域，假象一个十分配合的用户，能服务好他们的产品经理，就是一个90分的产品经理了；
• 好产品有其局限性，记得爱因斯坦说过嘛：The difference between genius and stupidity is that genius has its limits；
• 好产品是件艺术品，有人说设计不是艺术，他们说对了一半：坏设计不是艺术，好设计是。

有工程师分不清Framework与Library/Toolkit。一个比较简单、直观的检验标准是：Framework shapes applications：

• 如果最终应用的顶层设计可以按照该组件叙述，该组件可被称之为Framework，如Express、Backbone；
• 如果最终应用的顶层设计无法按照该组件叙述，该组件仅能被称为Library/Toolkit，如jQuery、D3

不知道我有没有解释清楚，一个Framework可以被当作Library被微观地使用，一个Library比较难被当作Framework上位成宏观架构。

与同类产品相比优势在哪

同类产品，你怎么定义同类产品呢？我觉得有两种产品跟微信应用框架相关，但并非同类产品：

• 某个运行时下的微信API接口，如PHP、Node.JS版，但我不认为与微信应用框架是同类产品。多数这样的SDK跟微信API是一个一一对应的关系，HTTP本来就是标准协议，这类产品想像空间实在有限；
• 微信API，我认为微信API也是微信应用框架的同类产品，你不认为么？有相同的用户：应用程序开发者。但是微信的API没有把开发者的痛点当作自己的痛点，也没有了解不同生态的开发者习惯，作为接口，设计得也不太美（对比GitHub的接口）。所以，你说Mongoose是MongoDB Node.js Driver的同类产品也可以。

微信应用框架是按照标准产品的设计步骤进行的（不要以为这会很慢），用户与Scenario分析，界面（对于Framework或Library来说，界面就是架构与接口）设计。而有些同类产品好像是重构的产物，重构并非不能产生好的Framework或Library，但是半生不熟的重构不可以，好的重构过程是Bottom-Up与Top-Down的综合结果，仅仅关注微观的重构，让我想起了“人类一思考，上帝就发笑”。

具体说，举3个例子：

• 点击文字是“天气预报”的按钮，向用户发送当日的天气，用微信应用框架来实现，是：

wx.click '天气预报', (req, res) ->
  res.text '晴'

• 一个昵称“蒋涛”的用户发送“你好”，回复“蒋涛，么么哒”，用微信应用框架来实现，是：

wx.text /你好/, (req, res) ->
  res.text "#{req.user.nickname}，么么哒"

• 在网页显示商品（或文章）二维码，用微信应用框架来实现，是：

<img id='樱桃二维码' src="/wx/qrcode?product=樱桃" />

在页面响应这个二维码被扫描的事件是：

wx.scan '#樱桃二维码', -> # 樱桃二维码被扫描

上面这3个例子，用同类产品来实现，加起来恐要近百行程序了。更多的例子在weixinjs.org上面都有，请花几分钟用手机边体验边了解。

所以，真正的区别是品味。那些有更多功能的、更早开始的、更多工程师参与的同类产品，缺少的是品味。不要误会我，这样说不是一种傲慢。品味是伟大作品、伟大的创意工作者培养的。品味促使设计者：

• 几于歇斯底里地自省，一定有什么地方做的不够好，是否真的非此不可？
• 这个叙事的最短路径是什么，哪几个包袱抖出来，这个故事就活了，少了一个也不行。

“微信应用框架”的运行状态如何

哈，我更想了解用“微信应用框架”来驱动的公众号的运行状态！

就框架本身而言：很遗憾，这个作品远远未臻完美，而我又可耻地投身于下一个事业，很希望有人能理解微信应用框架和同类产品的近百个细微差异，作为开源项目继续完善。

设计师需要鉴赏力，鉴赏力成就杰作。

BTW: “微信应用框架”是一个高中知识即可以完成的作品，同类产品的若干小小的缺憾，令我感叹国内原创性思维和品味的缺失，更可以理解产品经理与工程师之间的断档。自我安慰一下，可能最优秀的工程师都不在做application-level的设计吧，但是application-level很需要设计能量，需要很优秀的工程师、设计师；亦或许有些闭源的项目做的更好吧，希望如此！

weixin.csdn.net

没能做一个Keynote有些遗憾。

“微信开发大会”与“微信应用框架”是如此贴切，有了“微信应用框架”之后，每个实际场景最少1到3行程序就可以完成，开发者也不需要理解过多的微信的Jargon，文学化编程，是“微信应用框架”提供的全部。

希望Designeer们多挑剔“微信应用框架”，批评使产品进步。

看起来很厉害