很久以前，就在备忘录上面写好了这篇文章的大纲，希望抽个空把这个阶段前端工程化的一些心得以文字的方式记录下来，但是万事开头难，拖了很久。而且有很多东西我更提倡用面对面的交流去阐释，所以动手写这篇文章还是因为要在公司内部做一个分享会，算是先组织下语言吧。

我以前写了一篇博文叫 《Web-IM 系统的前端设计与实现》 大概的说了下当时的一些前端架构的东西。第一，那篇文章写的比较少，大概说了下；第二，前端技术发展的很快，现在这个项目的前端经过重构，已经完全跟当时不一样了，所以，还是另写一篇博文来细说下自己对前端工程化的一些看法及在项目上的实践。

由于本人能力有限，这篇博文也是以我目前最高水平能写出的东西，难免会有一些差错或不理想的地方，仅供大家参考，如果有任何的建议，欢迎 Email 我，一起交流！

目录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
技术选型

开发规范
- 编码规范
- 使用 jshint		

构建工具 - FIS 的使用
- 第三方组件管理
- 模块化
- 常规的性能优化
- 智能打包

模块化 - 组件式开发
- 目录规范
- 组件仓库
- 开发一个组件
- 通过事件进一步解耦

引言

前端发展的非常快，如果你是一个热衷于追求技术的前端，你会发现越来越多的开源项目和选择，让你眼花缭乱，措手不及。不过每个前端团队都需要打造自己的前端开发体系，同时前端工程化代表着现在的前端开发不再是那种简单而无趣的远古生物，而是一个很性感的、让你情不自禁的想要去深入的美女（别想歪，我可是很纯洁的！！）。

前端工程化需要哪些技术元素？让我引用瓶神的一张图来说明。因为太过于理论化的博文可能会有些无趣，我会按照自己对前端工程化的理解，重新组织文字来描述这些技术元素的构成。
image-1

技术选型

技术选型没有包括在上面图片的技术元素中，不过目前我所在的团队一个好的技术选型对于前端工程化有非常大的影响。可能在大的团队中，不需要技术选型，因为已经有很完善的技术沉淀，各种轮子都自己有。

  • 构建工具：FIS
  • 模块加载器：mod.js (FIS 自带)
  • MV* 框架：Vue.js
  • 动态样式语言：Less
  • 包管理：fis-components

其中 FIS 和 Vue.js 作为一个开发工具和一个开发框架，我认为在整个技术选型中非常重要，因为它们决定了项目迅捷开发的能力、后期的可维护性以及工程化的程度。

技术选型中最大的误区为了选择而选择，而是要充分考虑到项目实际、团队协作、可维护性、社区活跃程度等。

构建工具，我从 Grunt 换成了 FIS 是因为 FIS 更适合大型项目；模块加载器，我从 RequireJS 换成了 mod.js 是因为既然使用了 FIS mod.js 会更容易融入到项目中；开发框架，我没有选择 AngularJS，是因为 Vue.js 轻便，入手快，这样后面的成员会很快的加入到现有的开发中。当然，AngularJS 的生态会比 Vue.js 的好。

开发规范

正如瓶神所说，规范可以极大的提升开发效率，一个优秀的规范能帮助开发者快速定位问题，提升效率。而且如果团队中多人参与开发的话，开发规范还能保证代码的可维护性和可读性。

编码规范

每个团队均可以根据自己的实际情况去制定适合自己团队的编码规范，通过 Code Review 来确保这个规范被真正实施在团队的日常开发中。唯一要确保的是，在项目伊始，这个编码规范便应该被确立下来，在后期的开发中可进行小范围的调整。

这里有一个我觉得比较好的 HTML、CSS 编码规范

使用 JSHint

当然，有时候仅仅通过 Code Review 很难避免出现老眼昏花，毕竟年纪越大，眼神就越不好。所以，我们可以通过技术手段去加强编码规范在团队的推行。

  • 通过给 IDE 配置 JSHint 纠正日常编码习惯
  • 通过给版本控制仓库配置 JSHint 强制拒绝不规范代码的提交

按照我的经验，只需要一至两个月，团队成员在不需要 JSHint 的提示下就已经养成了书写符合当前团队编码规范的代码。