Open ccforward opened 7 years ago
由于前端触及的领域越来越宽，而且每条业务线的开发都有相同和不行痛的部分，所以通过公司业务实践和思考，从整体的角度对前端的体系做下总结。
目前的技术体系(正在用和正在开发的)包括这几个方面：
如下图所示：
js 基于 ES6 开发，用 stylus 做预处理器来提升 css 代码的可维护性(sass也是其他项目的可选项)，gulp/webpack+babel 做构建工具 固定项目的目录结构，方便统一构建的方式。
用 git 做版本控制，每次新需求都从 master 分支 checkout 出来，用 ESLint 静态检查做强制约束，通过 git 的 hook 保证 ESLint 不通过 git 就不能提交代码。
直接通过 git 发布当亲开发分支的静态代码，每次发布打版本 tag ，通过服务器的脚本自动将分支合并到master。
前后端分离
Vue.js zepto stylus React 都可选，根据业务的不同选择最优方案。同时用 Yeoman 开发出对应的脚手架工具，通过脚手架快速进行项目的而搭建和组件的开发
前端技术栈更新太快，所以技术栈的更新也配合开发构建工具的更新，这就像业务一样是个不断发展的过程。
根据构建需求开发 webpack 和 gulp 的插件来适应技术栈的更新和业务的需求。
因为用的都是开源的模块和框架，所以用 NPM 作为团队统一的包管理工具。如果后期内部的组件和模块丰富了，可以搭建一套内部的 NPM 来做包管理。
前后端开发不可能同步，所以开发一个 API Mock 平台来模拟 api 返回的数据，好处如下：
PS:这个 API Mock 平台正在开发中，简称 AMP(API Mock Platform)
痛点：
所以基于前端 TDD (Test-Driven Development 测试驱动开发) 能省时省力
有了 APM 平台也能快速的做接口的单元测试
关于 TDD 后面专门开一篇文章做总结
代码做过rview 并通过测试后进入发布流程
现在的统计监控是基于公司的一套上报系统来做的，后端已经相对完整，只需要前端做数据的上报即可。
但是现在的数据只是收集，还需要搭建一套通知系统，保证出现线上故障能够快速的修复
前端技术体系和结构
由于前端触及的领域越来越宽，而且每条业务线的开发都有相同和不行痛的部分，所以通过公司业务实践和思考，从整体的角度对前端的体系做下总结。
目前的技术体系(正在用和正在开发的)包括这几个方面：
如下图所示：
规范
js 基于 ES6 开发，用 stylus 做预处理器来提升 css 代码的可维护性(sass也是其他项目的可选项)，gulp/webpack+babel 做构建工具 固定项目的目录结构，方便统一构建的方式。
用 git 做版本控制，每次新需求都从 master 分支 checkout 出来，用 ESLint 静态检查做强制约束，通过 git 的 hook 保证 ESLint 不通过 git 就不能提交代码。
直接通过 git 发布当亲开发分支的静态代码，每次发布打版本 tag ，通过服务器的脚本自动将分支合并到master。
技术栈 & 构建
前后端分离
Vue.js zepto stylus React 都可选，根据业务的不同选择最优方案。同时用 Yeoman 开发出对应的脚手架工具，通过脚手架快速进行项目的而搭建和组件的开发
前端技术栈更新太快，所以技术栈的更新也配合开发构建工具的更新，这就像业务一样是个不断发展的过程。
根据构建需求开发 webpack 和 gulp 的插件来适应技术栈的更新和业务的需求。
因为用的都是开源的模块和框架，所以用 NPM 作为团队统一的包管理工具。如果后期内部的组件和模块丰富了，可以搭建一套内部的 NPM 来做包管理。
Mock 接口数据
前后端开发不可能同步，所以开发一个 API Mock 平台来模拟 api 返回的数据，好处如下：
测试
痛点：
所以基于前端 TDD (Test-Driven Development 测试驱动开发) 能省时省力
有了 APM 平台也能快速的做接口的单元测试
发布
代码做过rview 并通过测试后进入发布流程
统计 & 监控
现在的统计监控是基于公司的一套上报系统来做的，后端已经相对完整，只需要前端做数据的上报即可。
但是现在的数据只是收集，还需要搭建一套通知系统，保证出现线上故障能够快速的修复