模型
这个问题是突然之间闪现出来的，如果说MVVM中的modal是数据模型的话，那么数据模型又是什么呢? 是我们定义好的数据结构? 还是通过设计模式抽象出来的解决方案? 还是应该按照具体的情况来分。
在框架中就是数据模型，在具体的业务中抽象出来的解决方案也是模型，那么由此看来，能够解决问题的既定流程即可成为模型。当然，这些都是抽象的东西。
那么有没有具体的东西是模型呢？现在回想一下，之前学过的基础学科，其实就是学的模型。数学有和差化积，物理有w=fs,化学有H2O,不都是模型吗？
然后基于这些最基础的模型，发挥我们无尽的想象力，世界变得精彩纷呈。
模块
如果说模型是一些比较抽象的东西，那么模块儿相对来说就是些比较具体的东西了。现实生活中，盖房子用的预制板是模块儿，修建高速公路用的预制钢箱梁也是模块。
模块儿的好处在于提高生产效率。前端的模块儿化其实也是为了提高开发效率。相同的内容，经常使用的方法，封装起来，成为一个npm包，用的时候直接import，很方便。
组件
组件最开始的名字应该是代码片段。后来发现这些代码片段在项目里使用的次数很多，干脆将这些代码片段组织起来，给予统一的样式，方便在其他项目中使用。
基于代码片段的UI库有比较经典的bootstrap和layui,这些UI库在前端以jquery为主的时候发挥了巨大的影响力。
2013年react逐渐走进前端开发的视野，react文档中有一句非常有影响力的话，大意是：组件是 React 代码复用的主要单元。
然后2016年vue框架出现。随之而来的是基于前端的各种UI库，比较知名的i-view,element-ui。
对于公司来讲，组件化的好处是，如果我们有自己的设计团队，我们可以自己设计一套以用户为中心的，符合自身业务的组件，开发出用户体验比较棒的产品。当然，没有设计团队也无关紧要，开源的产品也基本上能覆盖我们的业务场景。
框架
模型，模块，组件，这三者结合起来是什么呢? 是框架。
回想一下我们创建项目的过程，不管你用什么脚手架，vue-cli,create-react-app或者你自己用npm init去初始化一个项目。有三个问题是必须要处理的:
- 项目结构
- 安装各种依赖包
- 安装UI库的组件包
项目结构可以看做是模型，依赖包可以看作是各个模块，UI库还是UI组件。理论上如果组件库的能力如果封装的足够强大，开发阶段我们甚至不用去mock数据。
比如我们将数据请求和mock功能直接封装到组件内，当然这只是我自己的一些想法。由此也会带来信息的问题，比如：如何调试？
架构
你有开发一个框架的能力，但并不意味着你具有架构的能力。
我们也许具有技术负责人的素质：
- 能够平衡业务进度与技术方案。
- 能够解决重要，复杂的技术问题。
- 能够帮助团队中其他成员快速成长。
- 也能够从全局考虑项目的技术和业务问题。
具有架构能力，我们似乎必须业务细节和技术细节都比较清楚才行。
- 项目搭建
- 工作流程设计
- 项目构建流程
- 项目持续集成方案
虽然每一项看起来都是那么几个字，但是里面的内容恐怕是有很多。
价值
当技术不再是问题时，关注点便在业务上。技术是业务价值的实现方式，但是业务才是赚钱的直接证明。
如果业务无法活下去，那么技术还有什么价值呢？
先进的架构，并不一定给业务带来价值。先进的技术，也并不一定为业务带来价值。
新的技术和架构，节省的往往是开发时间，而实施这些新的技术和架构，也会花费一定时间。
因此，大多数时候，业务人员考虑的业务价值，进度是他们考虑的第一因素。
小程序登录
小程序登录逻辑:
- 调用
wx.login获取code。 - 传
code给服务端,服务端通过auth.code2Session和微信后台服务交互,进行登录凭证校验。 微信后台返回session_key,openid给服务端,服务端生成自定义登录态token返回给前端。- 前端缓存登录态，进行业务请求。
登录流程图:
分析：
从界面展示来看，登录一般存在以下几种情况:
- 手机号 验证码登录
- 用户名 密码
- 微信授权一键登录
那么我们可以讲这个界面封装成一个组件，登录所需参数，及登录后回跳地址都作为参数，通过props传入，执行整个登录流程。
具体实现
代码仓库:https://gitee.com/mynoe/mini-share-platform.git
后期会逐渐完善TODO中相关内容，尽量将流程组件化。
