本文将基于笔者浅薄的经验总结和整理一个基本小程序的从零开发到上线流程。
从编码上讲小程序的开发非常简单，不过这是相对于目前流行MVVM的框架下的WebApp开发来讲的，换句话说再简单也需要完整的视图、脚本和样式以及服务端支持，在整个流程依上来说仍然是一个不小的体系。

整体架构差不多像这样

准备工作

小程序最直接的优势就是能消除浏览器端的种种适配与兼容问题以及能使用许多微信客户端提供的酷炫原生能力，而代价就是必须在微信后台做好种种配置，并在申请和认证过程中做出种种妥协。笼统来说必要的东西有一下几样：

• 小程序主体

即必须在微信公众平台上注册小程序并提供相关的主体信息，包括小程序名称以及业务范围，还有注册完成后的认证工作，这些直接影响到开发完成后的审核成功率。题外话是虽然现在小程序开放了个人的注册，但小程序本身目的在于提供具体的服务，服务内容不明确恐怕难过审核，这在笔者看来并不适合个人，终究只能玩玩罢了，个人小程序想上线还得先考虑清楚打算提供何种服务，以及没有支付能力带来的影响。

• AppId、项目管理和https

小程序申请完成后即可在后台得到自己的AppId与AppSecret用于开发。直接使用微信开发者工具进行开发个人认为是远远够了，不过这工具对小屏幕的电脑不怎么友好，开发工具内提供的能力已经基本够用来编码与测试了，目前发现客服消息是不能发起的，以及部分页面布局和样式会和真机有出入等问题。
微信给出的小程序的代码管理规则比较固执，一个小程序分别会有一个开发版、体验版和线上版本，并且在后台添加指定权限的人员，开发者只能访问开发版，体验者只能访问体验版，整个小程序项目的代码文件暴露出来的只有最表面的代码文件，配置与依赖之类的都是不用开发者操心的。
还有一个重要的东西就是https，也就是开发者自己的WebApi服务器必须使用https协议进行通信，这也是必须做的，因为小程序的架构下客户端与WebApi完全分离，认证就显得很重要了。

整体搭建

现在专注于小程序的编写，来讲讲小程序如何一点点搭建起来。
首先是一般目录结构，这里给出笔者的项目目录结构：

整体目录结构

其中assets用来放图片图标等资源，pages下是小程序的所有子页面，utils下是封装的工具代码，包括网络请求代码等的封装。
最后的三个app.xxx文件即小程序的全局配置。

• app.js内可以处理页面初始化时的参数处理等。
  比如说对外推广了一个带参数的小程序码，由用户扫描进入后，可以在小程序首页提取小程序码附带的参数，也可以干脆在app.js里来提取，并且可以在这个脚本中定义全局数据等。

• app.json内配置全局的标题啊背景色啊底部导航啊之类的以及子页面也必须都在此先声明。具体的配置规则见小程序的官方开发文档。

• app.wxss即全局的样式配置。
  其中小程序自带的许多组件的样式可以直接覆盖掉，选择器直接写组件名，比如说：

     page{
         background: #fff;
     }
     view,navigator{
         box-sizing: border-box;
         font-size: 32rpx;
         overflow: hidden;
     }
  

page选择器可以覆盖小程序页面本身的样式，view、navigator都是小程序具体的组件，就当是重写过的div标签来改。

具体页面搭建

页面

页面的搭建主要工作就是小程序提供的一堆组件的使用，其中view组件拿来当div用，可以在样式表内重写样式，还有几个很厉害的复杂组件，包括swiper-view可以拿来做可滑动选项卡和轮播图，image组件自带了图片的多种是配方式，以及多媒体组件和各种表单组件。除了组件之外就是一些指令的使用(借用angular的说法)，比如wx:if控制显示，wx:for控制遍历渲染，想吐槽的两点，一是这些指令要记得加双大括号来传入变量值，否则传的都是字符串，二是小程序的这些个指令的值仅支持直接的变量和值的比较，并不支持传入方法，连String.split都不行，这直接导致数据格式化很蛋疼啊坐等改善。

脚本

脚本中要做的事有两件。一是在页面渲染的各个生命周期下执行相应的代码，比如在页面加载时初始化数据，在页面隐藏(打开新的页面但当前页面已缓存)时保存数据，在页面显示(从新页面后退会当前页面)时更新数据，在页面销毁时关闭舰艇和轮训等。二是执行视图中绑定的各种点击事件啊组件值更改的事件啊的回调，比如最普通的bindtap绑定了方法后，此方法需在脚本中定义，当用户点击后即会执行。关于小程序的js脚本想吐槽的是其this指针非常蠢，一个页面里得有不少 var that = this; 这个语句。

WebApi配合

WebApi是除了小程序客户端本身外另一块需要开发者实现的东西，与公众号的网页开发一样，分为业务的Api交互和微信实时消息的转发和处理两个内容。总结下来常用的也就登录状态的保持(登录其实微信帮忙完成了，Api这边只需要生成自己的凭证用来与客户端交互)，媒体文件的上传与下载(用户上传下载的多媒体资源)，模板消息的发送以及支付回调处理等，当然自己这边还要提供所有业务数据的接口。还有一个客服消息的转发其实不需要自己来实现，用微信自带的就够了。

部分API能力

转发

小程序的转发和普通网页配置JSSDK转发类似，都是配置转发的内容和回调，但是能配置的只有标题，好在不需要去踩JSSDK这个天坑了，那玩意对SPA是满满的恶意。而且小程序的转发也不是非要用户点击右上角来实现了，可以配置到具体的页面按钮上去。

客服

小程序端法器客户会话很简单，使用指定的组件即可，如果不是非要自己搭一个客服消息转发API的话，加个客服消息组件就算是完成客服功能的接入了。

小程序码与二维码

小程序码和二维码现在变得成熟一些了，有多种码可以生成，有数量有限的和无限的，跳转到具体页面的和能带参数的，其生成由WebApi来完成，小程序端管显示和扫码进入时的参数判断就够。

支付

小程序的支付非常简单，调用指定接口即可，笔者看来这也极大的得益于免去了JSSDK这个祸害。

审核与发布

小程序的审核是一个蛋疼的过程，现在好像是稍微舒服了一些，但是笔者项目上周的提交审核(非首次)还是持续了仨工作日。总的来说就是微信那边会很认真的核对提交的小程序是否有业务的不明确以及页面布局或交互上的问题，对于不同行业的审核也有不同，审核时长非常看运气很被动，个人看来这虽然严谨但更新一次版本的时间成本略高。

最后再提一点，是小程序的官方开发文档还是比较完善的，开发过程中遇到什么问题时，先不必急着去开发者社区抱怨或者去开发群里贴图，多留意文档里那些说小不小的说明文字，真的解决不掉的话说不定还真是小程序自己的BUG，问别人也没用，只能坐等更新啦。