1.协作流程
WEB 系统：部署在 WEB 服务器上，用于为若干 WEB 客户端提供服务的系统
不同的 WEB 客户端根据用户的不同需求发送请求到 WEB 服务器上，WEB 系统根据需求返回相应的结果，最后通过 WEB 客户端展示给用户
典型的 MVC 架构的 WEB 系统
结构：控制层（Controller） 数据层（Model） 视图层（View）
数据层（Model）主要封装了对数据的管理（如对数据的操作）
视图层（View）主要展示了数据模型，提供人机交互功能
控制层（Controller）主要用来处理用户的请求，委托数据层进行数据相关操作，选择合适的视图返回给用户
一个典型的 WEB 系统各层之间的协作流程
在 WEB 客户端（浏览器）输入地址，按下回车时，WEB客户端就会发一个请求到服务器上，控制层（Controller）首先接收到 WEB 客户端请求并进行解析。通常这时候会请求数据层进行数据相关的操作，数据层（Model）根据需求筛选出相关数据模型，返回给控制层。
控制层将收集到各种数据模型转交给合适的视图层进行模板整合，然后视图层（View）将数据模型与模板整合之后生成页面代码，返回给控制层。
最后控制层（Controller）将结果返回给 WEB 客户端进行展示。
角色定义：完成 WEB 系统需要的角色
视觉工程师：交互原型转换为视觉稿
前端工程师：系统前端交互逻辑
后端工程师：后端开发技术，为前端提供数据、接口服务支持
前端工程师可切分为页面工程师和前端工程师
页面工程师更偏重与页面架构的实现，前端工程师更偏重与前端业务逻辑的实现
协作流程
拿到交互原型和视觉稿后，前端与后端沟通输出入口及同步数据规范与异步接口规范。
后端根据入口及同步数据规范配置、实现控制层，再根据异步接口规范实现接口。
前端根据入口及同步数据规范进行系统架构及模板实现，再根据异步接口规范进行逻辑实现。
最后前后端进行联调与测试。
核心输出
页面入口规范：定义系统对外可访问的入口，入口配置信息
同步数据规范：定义系统需要预先给每个入口的模板文件的数据信息
异步接口规范：定义前后端异步数据交互的接口相关的信息
职责说明
页面工程师
切图，优化图片
页面制作，优化页面效果与结构
完成简单的前端业务逻辑开发
前端工程师
主导制定前后端分离规范
主导前后端联调对接测试
系统前端设计架构，满足一定的功能性需求（性能，可扩展性）
完成系统前端的业务逻辑实现，优化实现逻辑
后端工程师
协助制定前后端分离规范
协助前后端联调对接测试
完成后端系统架构及业务逻辑实现
2.接口设计
页面入口规范：URL 地址跟模板与接口之间的约定
包含页面基本信息（访问地址，页面描述），输入参数（访问地址上支持携带的参数说明），模板列表，接口列表
同步数据规范：模板和数据模型之间的约定
包含模板基本信息（模板文件，模板描述），预填数据（全局+页面），注入接口说明
异步接口规范：接口与数据模型的约定
包含基本信息（请求方式，接口地址），输入数据，输出结果
规范应用：构建项目结构；模拟同步数据；模拟异步数据
本地开发
前端开发环境包含两部分，一部分是本地模拟服务器（Local Server），另一部分是本地代理（Local Proxy）
所有 WEB 客户端跟服务器端的交互都会被本地环境所拦截，WEB 客户端请求到真实的 WEB 服务器上的请求不会发生。
通过这种方式将前后端开发做彻底的分离
Local Server
WEB 客户端请求某个页面时，客户端发出的所有请求首先都会被 Local Server 拦截，通过配置信息，Local Server 可以识别出这些请求所对应的模板文件和模拟数据所在的位置，可将模板文件和模拟数据整合，直接生成 HTML 页面结构代码，返回给 WEB 客户端
Local Proxy
当客户端发了异步请求之后，请求会被 Local Proxy 拦截，根据配置信息，匹配信息找出请求所对应的模拟数据，如果存在模拟数据，直接把模拟数据转换成 JSON 数据对象或其他定义好的数据结构直接返回给 WEB 客户端
3.版本管理
版本控制系统 VCS （Version Control System）是一种记录若干文件的修订记录的系统，他帮助我们查阅或回到某个历史版本
四种 VCS：人肉VCS LVCS本地 CVCS集中式 DVCS分布式
人肉 VCS
无法找到需要的版本，也没法查看差异
污染工作空间，导致无法集中精力维护当前编辑版本
LVCS 本地式（RCS）
利用一个本地的版本数据库来存储版本
好处：需要哪个版本，只要从具体版里把它 checkout 即可，可以维持当前工作目录只是感兴趣的版本。
CVCS 集中式（CVS，SVN，Perforce）
利用一个中央的服务器进行日常版本控制操作，所有操作都必须经过中央服务器
在集中式版本管理下，可控性更高
但每一次操作都要经过网络请求，影响操作流畅性
单点故障：一旦发生故障，轻则无法进行相关操作，重则丢失历史信息
DVCS 分布式（Git，Mercurial）
每一份本地仓库都是一份完整的历史拷贝，即使用于同步的中央服务器发生故障，可以从本地仓库中将历史还原
好处：相关操作大部分可在本地，更流畅
分支模型
分支：从目标仓库获得一份项目拷贝，每条拷贝都有和原仓库功能一样的开发线，可在开发线提交代码，也可以退回到某个版本
分支模型（branching model）/ 工作流（workflow）
一个围绕项目[ 开发 / 部署 / 测试 ] 等工作流程的分支操作（创建，合并等）规范集合
产品级的分支模型
常驻分支：development（从 master 创建）；production（master）默认分支
常驻分支一旦被创建，就不会更改
活动分支：feature（特性分支，从development创建）；hotfix（bug修复分支，从master创建）；release（标识产品正式发布，从 development创建）
活动分支会跟着产品的发布而被动态的创建，有时在完成开发时删除，只留下对应的版本号
分支模型——特性开发，发布线
从 D 创建 feature1，feature2，两分支并行开发，feature1开发完成后合并到 D 分支，假如 feature2 后续开发依赖 feature1 提交，将 feature1 提交合并到 feature2 。
feature2 开发完毕，将其合并到 D 分支
所有特性开发完毕，准备合并回 release 分支
假设同时在开发另一个特性，但不在下一个版本发布，完全不受发布线影响，并行开发即可。
首先所有属性都已经合并到开发分支，准备发布。创建 release 分支，拥有当前 development 分支所有信息，在其中进行少量的 Bug 修复与数据更新。
所有在 release 提交的代码，都需要合并到 development 分支，将来更好进行版本回溯。
最后一次 release 分支提交，推送到 master 分支，打上相应版本号，可直接上线。
若存在线上 Bug，在小版本进行处理，代码修复的提交也需要合并到开发分支。
涉及的四个环境：
开发环境（feature分支）；测试环境（release/development分支）；预发布环境（release分支）；生产环境（master分支）
