文档介绍：前端开发的流程与规范
LT
        这套流程制定出来就一直要求所有前端组同学严格按照流程执行，也经过了很长时间的磨合跟改进。虽然不是很完美，但是很适合我们现在开发的需要，好处也是显而易见的，遵循并使用它对我们的发开有很大的帮助，能更好的应对高强度，高质量的开发需要。提高了团队的协作程度，代码更可控，开发效率更高。
 
=======================================================================================
 
我的理解
传统方式：产品经理产出 PRD -> 交互产出 prototype -> 视觉产出 mockup -> 前端产出 demo
LSM 方式：PRD -> prototype -> a). 前端做 html b). 视觉做 mockup -> 前端完善 demo
疑惑与讨论
1). 后续环节受前面的影响。这点上，两种方式都受影响。并且前端介入的时间越早，当 PRD 和 prototype 变动时，整体耗费的时间越多。解决此问题的关键不是流程顺序，而是保证流程产出物的稳定性。PRD, prototype, mockup 的稳定性，是减少返工的关键因素。
2). 网站的规范。这个和流程关系不大，难的是规范的制定。开发一个具体页面 page, page 处于某个应用 app 下，app 从属某个系统 sys. 当规范成熟后，开发顺序是：将 sys 规范应用到 page -> 将 app 规范应用到 page -> 进行与特定 page 相关的工作。前两步经常很快，耗时不多。
3). 标准模块，或者说是 DPL（设计模式库）。这个和规范类似，与流程关系不大。
4). 当规范成熟、标准模块成型后，传统方式的效率很高。LSM 方式中，前端根据 prototype, 应用 sys 和 app 的全局规范和标准，产出 html 是很快的。而视觉产出 mockup 是精雕细琢的过程，往往耗时较多。这导致的问题是，前端根据 prototype 能做的东西很少，依旧要等 mockup 出来后，才能开始耗时最多的工作。
5). 感觉克军的核心是推崇规范和标准模块的重要性，而不是流程。重要的是将可重用的设计和代码提炼归纳，成为共用的模式库。
6). 如果说有银弹，我觉得是 DPL. 前端的重用提炼为框架类库，交互的重用提炼为交互模式库，再加上视觉规范，就成型为一个个标准模块。每个模块，都凝结着交互、视觉和前端的提炼。
7). DPL 不稀奇。MS WinForms, ExtJS, Yahoo DPL 等，都是成熟案例。做到这一步后，产品经理甚至可以直接从 DPL 中挑选模块组建页面。交互和视觉，只需要关注整体以及与该 page 特定的交互和视觉，前端则关注新功能开发和页面整合。流程已经不重要。
8). 但是，Web 唯一不变的就是变化。高质量的 DPL 很难得，能随心所欲“变化”的 DPL 更难得。现实世界里，大量工作依旧无法模式化，银弹是不存在的。
我的想法
对前端开发流程，我的想法是：
假设 sys 级的规范和标准模块已经完成（包括全局样式、布局规范、标准盒模型等），这时需要