别急着动手

把玩过小程序开发的朋友应该都有一种直观的认识：

API 高度封装，精简

组件丰富，足以满足日常需求

官方工具齐备，云端解决方案到位

显然，微信团队以折损自由度的代价，辅之完备组件，配有一站式工具，换取傻瓜式的开发体验。

以此来博取开发者的青睐，甚至 “勾引” 零基础的人来尝鲜，以淡化人们对 WXML 这种全新的、封闭的 XML 拓展语言的抵触心理。（人们理所当然拥抱 H5 这种 W3C Web 标准规范，却不一定愿意倾注时间和精力去学习一门 封闭式、非标准化的私家语言）

抛开其他不谈，单就门槛而言，已经将到极低。

这容易给人造成一种假象，即小程序没有啥技术含量，所有的能力框架已经给出，原本需要一个月周期的 Web 、 App，用小程序实现大可缩短到 1 至 两周。

让这个结论成立，得满足一个前提，即只负责功能的实现，不考虑可迭代性或可测性。

然而不可迭代亦不可测的应用程序，我通常认为那只能是玩具 Demo。

互联网应用程序从来不是一触而就

生活里，工作中你所使用过的任意一款应用程序，哪怕是功能极简，哪怕是采用了某高大上框架开发，都离不开软件层面的构架设计、迭代计划和各类测试。

言下之意，好上手是一回事，把东西做好则是另外一码事。

so， 忘记小程序的便捷性吧，那只是个幌子。

正确认识小程序开发

WXML，玩过 Vue 吗？相似度高达 80%，玩过的话，扫下文档就可以上手撸个 Demo；

玩过 React 吗？ 组件化思想和生命周期 Hook 函数 一样一样的，玩过的话，只需熟悉下新语法；

如果曾经玩过 Angular， 简要替换下，还是可以快速上手；

如果玩过 React Native，那么这只是一次平滑的迁移。

说到底，小程序的意识形态可以说是国人首创（人口福利造就了微信，张小龙的野望，让 WXML 有了载体，不然这种只能跑在某 App 里的全家桶，谁会来玩呢？如果印度也有 “啊三信” 的话，小程序这种形态也是可以复制的）然而小程序的设计模式，实现原理，只是借鉴、沿袭了时下几大趋势：组件化，JS胶合。

只要是遵循组件化思想，总能从前端三大框架里找到影子，只要是 JavaScript 驱动，就可以复用状态机概念：Redux

言下之意，号称简单易用的小程序，终究离不开 View 层的状态与交互，数据流的绑定与控制。幸运的是，这些都有现成的解决方案，不幸的是，你必须用这些解决方案，否则在产品的路上，要分分钟失控。

现在来思考小程序的实现，该如何分工

业务逻辑、数据流控制 、静态资源、类库、工具函数和模版&通用组件应该相对解耦。可以通过目录结构来直观地分配。

• actions/

  • getRecords.js
  • getRecords.test.js
  • .....

• common/

  • constants.js
  • strings.js
  • apis.js
  • ......

• images/

  • logo.png
  • ......

• layouts/

  • home-list.wxml
  • ......

• libs/

  • redux.js
  • ......

• pages/

  • home/
  • me/
  • ......

• reducers/

  • home.js
  • me.js
  • ......

• utils/

  • getToken.js
  • getToken.test.js
  • formatDate.js
  • formatDate.test.js
  • ......

• app.js

• app.json

• app.wxss

我用了 Redux 所以会有 reducers 和 actions 目录。 reducers 存放每个 page 对应的逻辑分发和数据同步； actions 目录存放每一次 View 的交互逻辑，这两者是一一对应的，熟悉 Redux 的一目了然。

common 目录存放一些常量、字符串、API 资源 以便统一配置、调用。

layouts 目录存放一些通用模板，或者说可复用的组件，遵循组件化思想，尽量不重复自己。

utils 目录自然是放一些和主业务逻辑无瓜葛的通用工具函数。

其他目录无需赘述，都是些基本的命名和用法，这里面没有 test 目录，整个项目的逻辑已经被 Redux 解耦，所以我直接在 actions 目录里写一些功能测试，在 utils 目录里写单元测试，主要是引用方便吧，借鉴了 facebook 的 create-react-app 的做法。

说点和 Redux 相关的

Redux 是 React 生态圈的产物，一种类似 facebook 官方 flux 实现的状态机小类库， 但它适用于所有 JavaScript 驱动的前端框架；强调 View 层皆状态，一种状态对应一个 View。源码很精简，感兴趣的可以去 Github Review。

这里想说的是，有些同学知其然不知其所以然，上来就用了各种封装版 Redux，譬如 React 社区的 React Redux、React Router Redux；他们都很好用，但如果不明白 Redux 的实现原理就贸然使用，很容易迷失方向，丧失学以致用、举一反三的能力，会在 React 上用 Redux，却不能在 Vue、小程序里面用 Redux；其实作者也说了，直接 Redux 足矣，拓展封装并不是必须的，只是方便（本人觉得并不方便）小程序也有 Redux 的拓展封装，我没有用，个人认为，简单的事情就应该简单办，某些重复是必须的，因为那样可以让事情更清晰。

Redux 是函数式实现，强调不随意改动数据，正常情况下只在开启监听时初始化一次数据，此后所有的状态都交由 Redux 来内部处理即可（React 在最外层组件 set 一次 State 和开启监听、小程序比较繁琐，需要在每个 page 里分别 set 一次 Data 并开启 subscribe 监听）。如此一来，项目的业务逻辑完全可以剥离出框架，起到高度解耦的作用，这为可迭代和可测试铺平了道路。

说了那么多，晒下代码吧，欢迎指正