《微信小程序七日谈》系列文章：

1. 第一天：人生若只如初见；
2. 第二天：你可能要抛弃原来的响应式开发思维；
3. 第三天：玩转Page组件的生命周期；
4. 第四天：页面路径最多五层？导航可以这么玩；
5. 第五天：你可能要在登录功能上花费大力气；
6. 第六天：小程序devtool隐藏的秘密；
7. 第七天：不要捡了芝麻丢了西瓜

本系列的文章并非初学教程，而是笔者在具体开发过程中遇到的问题以及部分解决方案。

前几篇文章主要记录了开发一款微信小程序应用中的一些问题和解决方案，从2017年1月9号第一批小程序正式发布以来，至今一个月左右的时间，随着人们对于微信小程序讨论热度的慢慢降温，业界趋向于更理性的看待微信小程序。

本文从技术和产品的角度简单记录一下笔者自己一些粗浅的感想。

技术看小程序：又一个轮子而已

其实微信小程序的技术开发难度相比较纯粹的web客户端开发要简单很多，一方面是由于小程序对于常见功能API的统一封装，开发者不用关注客户端兼容性的问题；另一方面，小程序只提供了有限的功能API，并且限制了未提供的功能，这种限制令一个小程序产品在规划功能时局促在有限的范围内，也就间接降低了技术开发的难度。

前端工程师上手微信小程序开发非常容易，基本看俩小时文档就可以了。稍有难度的服务端的开发，由于小程序的一些限制，导致原来web浏览器环境适用的解决方案并不能照搬（比如登录功能），增加了服务端的开发工作量。

总体来说，微信小程序开发的技术难度不高，只是需要时间适应。

产品看小程序：盲人摸象

小波澜：罗辑思维和今日头条

2017年1月15号，距离第一批微信小程序的正式发布不足一周的时间，罗辑思维出品的微信小程序“得到”宣布下架。同一天，今日头条的小程序“今日头条Lite”也被传停止了服务。

朋友圈热传的罗振宇对于小程序的评价 - “我们决定不做了。我们知道小程序是什么了。哈哈，但是不能说。”这句话令很多人猜测小程序自身到底发生了什么。

到底小程序适合什么类型的产品

其实罗辑思维的退出并不是因为小程序发生了什么事情，而是“得到”这个应用的产品类型并不适合用微信小程序的方式承载。

微信小程序的定位是：无需安装、用完即走。而且入口只有扫描二维码或者朋友分享，甚至不支持朋友圈分享。对于到底怎么定位微信小程序每个人可能都有自己的见解，笔者经历的团队中就有多个不同的声音。大领导把小程序当做一种流量入口（目前看来这是最不靠谱的...）；产品经理们把小程序当成他们理解的另一个H5，所以功能完全照搬了webapp，完全没有考虑技术上是否可实现，导致开发进度多次停滞；操刀的技术开发人员把小程序看成又一个轮子而已，开发难度不及普通webapp的一半。

当然，以上是不同岗位的人群对于小程序的不同看法。其实具体制定小程序应用定位的是产品，网上有很多先行者对此进行了大量的讨论，比如知乎的热帖微信小程序上线后，市场反应如何？，其中不乏理性的声音。

以笔者使用过的几个微信小程序为例，简单说一下自己的感想。

1. 今日头条Lite

这是笔者认为最不适合小程序的产品类型。今日头条的优势在于根据用户的浏览习惯进行智能推荐。这个优势的前提是用户有足够的粘性，长时间多内容的浏览才会对用户兴趣进行更精准的算法定位。但是“用完即走”的微信小程序用户并不会花费大量的时间在一个内容平台上浏览信息（要不然就没法微信聊天了，哈哈），这就令今日头条的优势荡然无存。

2. 美团外卖

这是笔者认为最适合小程序的产品类型。选外卖、付钱，然后就等快递了。不需要再打开小程序看订单状态了，虽然外卖订单有状态信息推送，但我相信大多数人是不看的...

3. 赶集找工作

首先吐槽一下这个小程序必须要登录才能使用，非常蛋疼的设计。用户对于这种找工作应用最依赖的功能并不是浏览招聘信息，而是消息推送（比如最新招聘信息推送、简历状态推送等），这与外卖类软件是完全相反的。所以这类应用并不是“用完即走”的，而是“用完就等消息”。

总结以上，笔者个人认为最适合小程序的产品类型是：低频交易类应用。

总结

总算把微信小程序七日谈系列完结了，洋洋洒洒写了几篇对小程序的一些见解和解决方案，都是个人的理解，难免浅薄了一些，大家权当参考吧。