本文將基於個人淺薄的經驗來總結和整理一個基本小程序的從零開發到上線流程。從編碼上講小程序的開發非常簡單，不過這是相對於目前流行MVVM的框架下的WebApp開發來講的，換句話說再簡單也需要完整的視圖、腳本和樣式以及服務端支持，在整個流程依上來說仍然是一個不小的體系。
整體的基本架構像這樣：
准備工作
小程序最直接的優勢就是能消除瀏覽器端的種種適配與兼容問題以及能使用許多微信客戶端提供的酷炫原生能力，而代價就是必須在微信后台做好種種配置，並在申請和認證過程中做出種種妥協。籠統來說必要的東西有一下幾樣：
1. 小程序主體
即必須在微信公眾平台上注冊小程序並提供相關的主體信息，包括小程序名稱以及業務范圍，還有注冊完成后的認證工作，這些直接影響到開發完成后的審核成功率。題外話是雖然現在小程序開放了個人的注冊，但小程序本身目的在於提供具體的服務，服務內容不明確恐怕難過審核，這在筆者看來並不適合個人，終究只能玩玩罷了，個人小程序想上線還得先考慮清楚打算提供何種服務，以及沒有支付能力帶來的影響。
2. 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，問別人也沒用，只能坐等更新啦。