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 并通过测试后进入发布流程
统计 & 监控
现在的统计监控是基于公司的一套上报系统来做的,后端已经相对完整,只需要前端做数据的上报即可。
但是现在的数据只是收集,还需要搭建一套通知系统,保证出现线上故障能够快速的修复