写博客的好处是给自己留下些痕迹，多年以后回头看看，除了琐碎之外还有些沉淀。
前端团队从无到有，虽工作内容不值一提，倒也是麻雀虽小五脏俱全，自己也是思考了一些东西，简略纪录如下：
人员任务分配：
前端本身的组成内容分为CSS3，HTML，Javascript三块。前两者相对联系紧密，往往HTML结构与CSS选择符是强耦合，修改样式必定要修改DOM结构，所以前两者(CSS,HTML)由一个人统一负责，这个人我们可以叫CSSer。Javascript负责业务逻辑实现和无法单纯使用css实现的显示效果，后面简称为JSer。
工作流程：
产品需求定稿 －－》UI设计提供视觉稿－－》前端（包括Csser，JSer）分析可行性，工作量评估－－》Csser根据产品描述和UI设计撰写静态网页，实现UI效果；JSer与后台讨论约定接口契约－－》UI设计复核静态页面实现效果 －－》JSer基于静态页面实现业务逻辑和需要JSer配合的动态效果 －－》UI设计复核页面实现效果 －－》产品复核业务逻辑实现效果－－》提交SIT测试－－》提交UAT测试－－》提交预生产测试－－》发布生产
采用这种工作方式可能存在的问题是：
1. JSer需要实现的静态页面才能开始工作。解决方法：CSSer配合UI设计尽早开始参与下一版本的静态页面开发；
2. 静态页面的更新导致JSer返工。JSer使用JS模版（http://underscorejs.org/#template）来转换静态页面。由于CSSer后期可能对静态页面进行修改，JSer这时候就需要对比静态文件来更新模板，而这种对比往往很费时。由于Javascript使用的模板是有Javascript逻辑嵌入其中，跟Javascript实现逻辑是强相关的，而CSSer又无法take模版的任务。解决方法：CSSer在将静态文件给JSer以后如果再有改变，尽量少改变HTML结构，如果HTML结构需要改变可以邮件通知改动了哪里；
3. 复杂的样式问题仍然可能涉及CSS和Javascript的协同；
4. 前端人员比较少的话，很难分这么细；
5. 契约接口变更考虑不全可能导致契约变更，导致前端重复工作;
6. 每个项目的参与者包括CSSer和JSer两个人参与，可能存在交流沟通的消耗；
7.单纯的css和js的分离开发方式导致每个人的技术成长存在限制，不适合全栈方向的发展。
框架技术：
underscorejs.org（工具类，操作后台的JSO数据，提供前端模版实现JS和HTML分离（http://underscorejs.org/#template））
zeptojs.com（移动端Jquery的轻量级替代，用于DOM操作）
jquery.com (pc端操作DOM)
backbonejs.org（提供单页应用的MVC结构和页面路由）
dojo(http://dojotoolkit.org/)提供后台管理系统的复杂插件
grunt(http://gruntjs.com/)对前端代码进行打包混谣合并
requirejs（http://requirejs.org/） AMD加载器组织JS代码
nightWatchjs(http://nightwatchjs.org/) JS单元和功能测试
JSDoc(http://usejsdoc.org/)代码注释和API文档生成
expressjs(http://expressjs.com/)前后端并行开发时候的数据模拟
mongodb(https://www.mongodb.org/)测试和模拟数据的存储
编码规范：
1. 优先使用CSS3特性，在一些低端版本的机器上实现基本显示，向下兼容。CSS文件单独存放目录。页面中不写死style样式，CSS提供类（class属性）嵌入页面实现显示效果；
2. 所有ajax请求在错误状态需要显示错误信息，可以使用封装的同一方法处理；
3. 页面中不允许引用不需要（或间接引用）的AMD资源模块；
4. 变量、函数、文件命名使用英文驼峰命名，不在页面中使用无语义的命名；
5. 在使用对象的属性时候要判断对象本身是否是object or domNode；
6. 存在if需要同时存在else分支