前言
從接觸小程式開始，到現在大大小小做了差不多有五六個小程式專案了，小專案的只有幾個頁面，大的專案有幾十個頁面。此篇文章是對之前專案的一個總結，專案的腳手架，開發框架和後期的優化是一個逐漸進化完善的過程，如果你打算開發小程式或者已經在開發小程式，相信這些經驗對你會有一定的幫助。
腳手架
小程式開發者工具可以直接編寫小程式的，但是開發工具就像武士手中的劍，多年磨鍊，已經達到人劍合一了，突然換把武器，那勢必影響殺敵效率，所以使用自己熟悉的開發工具還是很有必要的。
本人所在的公司基本都是中小型公司，專案開發週期都很短，前期的準備工作最多也就幾天時間，所以自己去擼一套腳手架然後用於專案開發，難度比較大，在網上找優質的資源是最好的選擇。
大佬justjavac的開源專案 微信小程式開發資源彙總，涵蓋了大量的優質小程式開發資源，在此推薦一波。
當然，腳手架的選擇也是視專案而定的，如果只有幾個頁面的專案，搞一套很重的工具未免有點畫蛇添足了。我們的做法是小專案，直接擼，大點的專案選用網路上的優質資源+自己改寫。
- 17年的電商專案，模組不多，採用的腳手架比較簡單，使用gulp監聽檔案改動，實時編譯，支援ES6+語法。
- 18年中旬的電商專案，到了新的公司，當時選用了WePY進行開發，特性簡單介紹下：
- 類Vue的開發風格
- 元件化開發（WePY出來的時候，小程式還不支援元件）
- 支援載入外部NPM包(小程式原生也支援)
- 使用babel編譯，支援ES6/7的語法
- 針對原生API進行優化
詳細介紹請點選WePY文件進行檢視，後續框架選擇上也會提到，差點被這框架害慘了。
- 最近的一個地產專案，也是下一個專案打算使用的，weapp-start，上文提到的小程式開發資源彙總中也有提到，特性如下：
- 支援 npm 包引入
- 支援 promise, async/await 等最新語法
- 支援多種編譯器，如 pug/less/stylus
- 支援 ESlint
- 支援本地 mock 資料
- 支援一鍵生成專案，元件模版
- 支援釋出前資源壓縮
- 支援自定義外掛
- 多種工具，加速開發
專案的地址為weapp-start，其中weapp-plugin-require（分析依賴，匯入第三方 npm） ，存在問題，window作業系統會出現路徑錯誤，我已修復，並給作者提了PR，但作者並沒有修復這個問題，如果有同學要用到這個腳手架，請下載我修改好的檔案進行替換，下載地址。
另推薦我根據weapp-start搭建的環境，目錄結構為：
├── README.md // 說明文件
├── dist // 編譯後的程式碼，用小程式開發工具開啟此資料夾
├── mock.js // 模擬資料的檔案
├── package-lock.json
├── package.json
├── project.config.json // 專案配置檔案
├── src // 專案程式碼都在這個資料夾下
│ ├── app.js // 等同於小程式根目錄下的app.js
│ ├── app.json // 等同於小程式根目錄下的app.json
│ ├── app.wxss // 等同於小程式根目錄下的app.wxss
│ ├── assets // 專案中使用到的靜態資源
│ │ └── images
│ │ ├── example
│ │ └── tab
│ ├── components // 公用的元件
│ ├── page // 存放小程式的各個頁面檔案
│ │ ├── example // example 頁面
│ │ │ ├── components // example頁面中的元件
│ │ │ ├── index.js
│ │ │ ├── index.json
│ │ │ ├── index.wxml
│ │ │ ├── index.wxss
│ │ │ ├── services // example頁面中介面
│ │ │ ├── template // example頁面中的模板
│ │ │ └── wxs // example頁面中的wxs檔案
│ │ ├── globalStore.js // 全域性共享的資料
│ │ └── test
│ │ ├── index.js
│ │ ├── index.json
│ │ ├── index.wxml
│ │ └── index.wxss
│ ├── template // 公用的模板
│ └── utils // 公用的方法或工具
│ ├── config.js // 全域性的一些配置資訊
│ ├── create.js // 狀態管理外掛
│ ├── mitt.js // 狀態管理外掛
│ ├── obaa.js // 狀態管理外掛
│ ├── util.js // 公用方法
│ ├── wxRequest.js // 封裝的小程式請求資料方法
│ └── wxapi.js // 對小程式api進行Promise封裝
└── weapp.config.js // 對腳手架的配置檔案
複製程式碼專案地址為點選檢視，覺得有用的請Star或者fork喲。
當然，網上也有很多優秀的腳手架，大家可以根據自己的需要選擇喲。
小程式開發框架
17年的專案並沒有使用開源的框架，直接使用原生小程式寫的，開發過程印象中並沒有很多的坑，只記得當時用到了一個富文字的外掛，wxParse，現在已5000多個Star了，雖然現在小程式有了富文字元件rich-text，但在最近的專案中還是用了這個外掛，因為後端的兄弟說，他們不能將html轉成rich-text需要的資料格式，後端是java的，有使用這個元件的同學，麻煩下面留個言，我要去鄙視後端一下。
前文提到自己在專案開發過程中使用過WePY框架，那麼下面我就簡單列一下現在比較火熱的三大小程式框架WePY，mpvue和Taro的特性，然後著重說下WePY：
- mpvue（美團）
- 徹底的元件化開發能力：提高程式碼複用性
- 完整的 Vue.js 開發體驗
- 方便的 Vuex 資料管理方案：方便構建複雜應用
- 快捷的 webpack 構建機制：自定義構建策略、開發階段 hotReload
- 支援使用 npm 外部依賴
- 使用 Vue.js 命令列工具 vue-cli 快速初始化專案
- H5 程式碼轉換編譯成小程式目的碼的能力
- taro （京東）
- React 語法風格
- 支援使用 npm/yarn 安裝管理第三方依賴。
- 持使用 ES7/ES8 甚至更加新的 ES 規範，一切都可自行配置。
- 持使用 CSS 預編譯器，例如 Sass 等。
- 持使用 Redux 進行狀態管理。
- 持使用 Mobx 進行狀態管理。
- 程式 API 優化，非同步 API Promise 化等等。
- WePY （騰訊）
上文已列出，此處不再贅述
三大框架分別是國內三家大佬的前端團隊產物，印象中mpvue和taro都是18年下半年出來的，WePY出來的最早，幾乎和小程式同步。
mpvue擁抱了vue，taro擁抱了react，WePY握住了vue的手，mpvue和taro都沒有用過，我們只是開發個小程式，不用做到H5和RN共用一套程式碼，所以18年中開發的一個電商小程式選擇了WePY，畢竟騰訊的產物，親兒子。
後來瞭解到，是騰訊的兒子沒錯，不過是養子，WePY本來是騰訊內部一員工的個人專案，後來騰訊團隊看這個專案不錯，就由官方來維護了，由此帶來了一些問題，曾在掘金看到過對WePY作者的專訪（好像是專訪，文章我找不到了），作者自己也承認，WePY前期的一些核心程式碼存在的缺陷，後期很難修復了，像髒檢查機制，據說2.0會有很大的改變。
貼一張WePY其中的一個Issue，我們當時的心情和他是一樣一樣的，不過我們不用重構了，專案死掉了，哈哈哈哈（悲涼的笑）
自己曾經寫過一篇wepy+weappx開發小程式遇到的坑以及解決方案，文中列舉了開發過程中遇到的一些問題和解決方式，在此就不贅述了，想了解的同學可以點選檢視。
如果你要問我開發小程式選擇那個框架合適？我只能給出一個建議，根據需求來定，如果只是單純的想做個小程式，就不要用框架了，小程式的語法目前已經很完善了，何必要去學習兩套語法呢，出了問題，又改不動他們框架，一句話概括下就是，小程式原生有的問題他們肯定有，原生沒的問題，他們可能給你造出來。
當然，如果有寫一套程式碼適用H5和RN,那麼可以考慮下mpvue和taro，作者更新很頻繁，有團隊維護，至於能不能提高效率，還得看需求，我們現在是不會選用任何框架了，小程式已經玩的很熟，沒必要再折騰了。
小程式開發建議
在開發過程中，我們總結了一些感覺比較好的開發實踐，在此奉獻一波，大佬別笑哈。
- 目錄結構
上文中腳手架第三項中貼出的目錄結構，是目前我們覺得比較好的一種形式（參照umi專案的建議），按頁面組織程式碼，將一個頁面所需要的內容放在同一個資料夾，方便日後的維護和有類似頁面開發時候的複製，存在公用元件的時候，放到外部的資料夾中，當一個專案大了以後，這種目錄結構，真的很方便。
- 元件的層級
元件的層級真的不能太深，2層最好，不能超過3層，之前專案有的封裝元件過度，層級太深，後期維護，根據資料傳遞一層層的去找程式碼，簡直不要太爽（反話）。
- 狀態管理
目前小程式能用的狀態管理框架也是比較多的，Redux，Mobx，還有基於Redux二次開發的像weappx，都很好，在這推薦兩個自己用過和打算用的，使用過的weappx，打算用的omi-mp-create，專案比較小可以不用，大專案還是用上吧，都放到global中，不好維護。
- 頻繁setData的功能放到元件中
電商專案中，少不了類似倒數計時這種功能的，像這種需要頻繁setData操作的功能，應該單獨放到一個元件中，為啥呢？當你setData的時候，小程式會有一個遍歷監聽了data資料方法的過程，比如當你setData的時候，小程式wxs中的函式都會執行，在我上文提到自己的腳手架中有這個例子weapp-quick-start，感興趣的可以測試一下。
- 使用WXS
小程式對js表示式的支援並不是很好，當然，就算可以，我也曾見過這樣的程式碼
<block wx:if="{{drawgift.giftDetail.virtualGoods.length>1||((drawgift.giftDetail.realGoods.length>0||drawgift.giftDetail.couponGoods.length>0)&&drawgift.giftDetail.virtualGoods.length>0)}}">
複製程式碼把這些判斷的邏輯放到wxs中，統一維護豈不是美哉。還有一點，官方說在 iOS 裝置上小程式內的 wxs 會比 javascript 程式碼快 2 ~ 20 倍，所以，能用還是要用起來的。
- 控制包的大小，分包載入等
不用的包，別偷懶，統統刪掉，至於分包載入等，推薦看下這篇文章，我就不囉嗦了微信小程式：一些執行細節及針對性的優化策略
結語
文章中涉及到的具體的技術點不多，更多的是對走過的路的一種回顧，覺得有幫助的童鞋，點個?喲！