best-practice-about-frontend-dev

记载一些实践出来的自我感觉良好的最佳实践经验总结，其实就是一群码畜的记事本，看了可以让你多出一些滚床单的时间

把目的摆在桌面上

做前端开发的程序猿，经常面临着代码重用度低的问题，前端的开发，很大一部分时间里是在写 html+css，虽然有 emmet ，less 等强悍的东西，但始终逃避不了代码量巨大的问题

初级的代码复用，通常就是将样式和 html 以widget形式组织在不同的文件夹里，然后就复制粘贴到页面上去，不到几天，会发现改一个代码要同时改好多个地方，且不知道哪个地方的代码更改才是最新的

前端代码量是巨大的，且时间通常是很紧迫的，前端团队需要尽可能快速的做出反应

样例代码近期在整理，由于自己也不是十分把握得觉得自己的觉悟很有用，但至少是帮上了自己的忙，算是小有所成，在样例代码还没出来的前提下，我就描述下我是怎样做一个页面的开发的

拿到美工的效果图
根据效果图将网页切分成几个widget
建立widget a, b, c ..... 的文件夹
每个文件夹下有 css, js, examples, img, tpl, tpl-compiled, sample-data 这几个文件夹
在examples 里新建一个 index.html; css 里新建对应的 init-widget-a.less，widget-a-config.less, widget-a-colors.less; js 文件夹建立init-widget-a.js；tpl 里放mustache语法的模板, widget-a.tpl； data-sample 里放和后端人员商议好的数据格式，data.json；tpl-complied 放模板 widget-a.tpl 和 data.json 的编译结果，widget-a-sample-html.html;
examples 里用 fis inline 编译后的 widget-a-sample-html.html, 引入 init-widget-a.css, 引入 seajs, seajs.use('init-widget-a.js');
这样大概的一个widget 骨骼就架设完成了
开始开发静态页面效果，css 用的 aliceui 的一些东西（因为兼容ie6），js 用的 aralejs （也是因为兼容ie6，且用spm工具安装很方便）；
开发完 widget 之后，用 grunt 将其打包
开个sites文件夹，子目录是站点，再子目录是页面，页面目录放一个 index.html inline 和许多要用到的 widget widget-a-sample-html.html， less import 对应widget所需的less，seajs，require 所需的widget js脚本
进行 fis release 发布，这是就可以看到一个完整的页面引用了开发出来的widget的效果页

多个页面重复使用相同wiget的问题
后端人员更改 html 结构代码前端人员可以快速反应，只要数据格式不做大改变
后端的人员完全不用动到 js，css 这一块东西，基于页面来引用所需的wiget，当widget源码改变的时候，重新导出一份新的资源直接发布就行，不用到处复制代码
利用了 arale 的组件，让不懂js的人也可以很快的开发出widget出来，换句话说就是直接降低了写代码这个人他所需储备的知识和经验，开发的人只需要看得懂文档，遵守命名规则，就可以写出一个widget
这样几个前端可以同时开发一个页面，最后导出页面所需资源文件就可以了，后端的人需要的只是 tpl 模板文件

当我这种方式开发的时候，我下达给下属的指令变得更加的单一和更有明确性了
页面出现bug的时候，可以很方便的追踪到写bug的人是谁
团队之间用 sourcetree 配合 github 的private 账户，感觉很舒服
但是目前有个问题就是，当页面多起来的时候，widget的引用变得代码量有点多，但还是比原来的开发大大的改善了
还有个问题，有些地方明显是应该分成两个 widget ，但是代码之间又非常的相似，这样的话开发成两个 widget 就有点过于冗余了，且变得难以维护，现在给自己下的规定就是，当一个地方的widget重用度低于三处地方的时候，就不精细的将其抽出为一个公用组件，因为前段代码，某种程度上属于易耗品，几乎每次改版，之前做的东西只有复杂的部分可以留下来，所以在冗余和结构明确上，我选择了结构明确，我觉得我是对的

mark 一下，已经很快就可以把样例push上来了，最近没时间，等过几天出远门在机场可以有空干这件事就目前自己的感觉而言。。。太爽了。。。

当运行 grunt build-all的时候，会按顺序做以下的事情