堆糖前端工程化的思考和实践

[iscarecrow]

初入堆糖版本

2014年刚到堆糖，整个堆糖的前端架构，只有PC端业务。存在如下问题

• 技术栈jquery方案，代码可读性规范不够
• 前后端耦合，freemarker方案，模板前端维护，模板的宏方法后端维护。职责不清
• 开发环境，ssh到服务器，vim修改java启动脚本启动jython应用，对于一般前端开发而已，上手成本太高
• 模块化， importJavascript方法，无依赖关系加载
• 打包方案，基于python+YUI， 正则关键词合并，不受前端控制
• 缓存更新，采用手工加timestamp方案。
• 发布包版本控制，手工回滚
• 依赖包管理，无包管理。采用手工引入第三方库。 有压缩库，有没有版本的库等问题。无法更新和包替换
• 代码管理，svn。 缺乏分支命名规范

存在这么多问题的情况下， 只能逐个击破。老代码不敢动，前端工程化需要运维同学配合，前后端耦合职责不清等诸多难点。对于新启动的项目，全部采用新方案处理，老的代码因为维护性相对弱，代码本身业务逻辑不动，把其他问题处理掉。

前后端分离方案

后台应用，移动应用。不需要seo方案的app。全部走api方式，与后端约定api json结构。不管是基于Angular，React，Backbone还是前端模板。都采用api获取数据，前端渲染的方案。前端后端项目可分拆维护。

{
	start: 0,
	limit: 10,
	hasNext: true,
	object_list: [
	]
}

模板方案

对于轻量的页面级别开发，统一采用handlebars作为模板引擎，增加代码的可读性。

开发环境支持

• 本地开发
• 远程开发，测试部署

本地开发针对react-web采用express，本地代理api。方案如下webpack-hugin-demo

为什么需要远程开发，或者部署?
后台渲染方案，后台服务提供开发api，测试人员需要访问应用等需求。需要远程提供部署。
此方案，后端采用docker做容器，ci打包后，使用包部署。(非前端)

打包方案

打包方案，统一由gulp处理。 包括流程：合并，压缩，换戳等。最后以bash脚本提供给后台ci流程，打包。方案如下gulp-package-hugin-demo
打包后输出内容

- templates  需要推送给web应用的模板
- statics 需要推送cdn的静态资源

模块化及模块依赖问题

• requireJS 可参考 require-mutientry-hugin-demo
• es6 import ， 使用webpack开发编译

原先的模块加载方案

ImportJavascript.url("/js/core/comm/pack.js");

(function(){
	ImportJavascript = {
		url:function(url){
			var domain = '';
			var scripts = document.getElementsByTagName('script');
			for( var l=scripts.length,i=l-1; i>=0; i-- ){
				var src = scripts[i].src
				if( src && src.indexOf('duitang') > -1 ){
					domain = src.replace(/^https?:\/\//ig,'').split('/')[0];
					break;
				}
			}
			document.write("<script type=\"text/javascript\" src=\"http://"+domain+url+"?"+(new Date().getTime())+"\"></scr"+"ipt>");
		}
	}
})();

加载时，采用此方案，加载依赖的js。但是在开发环境并未考虑加载顺序，模块依赖顺序等问题。

模块化方案，采用jquery隔离作用域空间

;$(function(){
	// page.js
})

包管理方案

node 和前端包全部采用npm管理

代码管理

切换成git。
分支规范分成feature/fix两个类型开发。 命名为{authorName}/feature/20061010/{branchname}。

如果对于大型项目而言 可以采用 先check出 release/project 在此分支切分再合并到master的方案，可以在此分支上处理多人合作的冲突等问题。

组件化

早期是jquery的插件化管理。css命名以插件名开头。

$.fn.pluginA = function(options) {	
}

$.pluginB = function() {
}

后台的angular项目采用， directive封装组件。 类似图片上传，表单提交等
react项目采用，react类实现。

代码规范问题

css 公用类型，组件类型，页面类型等
采用 cm- cp- pg- 开头拆分，引入sass做css管理

参考 airbnb/css

发布包版本管理

早期运维合并，出错后运维找前端回滚，重新发布的方式，人为控制最新上线代码。 后期引入ci系统，每次打包后，生成不断递增的包（10.zip）。可查询到对应的git hash和对应的打包时间。 如果线上发包出错，采用旧包部署。

后记

由于小团队背景，更多的是以业务导向型的开发。所以很多其他方面想做的事情，存在缺乏尝试或者没有上线等问题。原因主要来自两部分，个人精力以及团队实力是否能够承受更具有成本的技术本身。

比如：

• 前端性能监控工具
• 开发流程，打包速度优化webpack打包速度优化
• 通用化UI组件库
• 代码没有强制性jshint
• 单测推动不明显
• 服务器渲染react服务器渲染入门
  等

推动这些事情包括了技术，沟通，开发等各方面流程，从成果上看：相比早期工程化的一片蛮荒。现有前端包括开发，部署，发布，规范，技术栈等都做了更加现代化前端的实践。 不过有些事情上做的还不够深入，希望以后能够有新的2.0版本产出 σ`∀´)σ。