克军在 WebRebuild 中分享了《LSM 实践》，很不错的议题。下面是我的一些想法。
我的理解
传统方式：产品经理产出 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 级的规范和标准模块已经完成（包括全局样式、布局规范、标准盒模型等），这时需要开发一个项目，假设为淘江湖 SNS 项目。理想中的开发流程为：
a). PD 产出 PRD.
b). 交互统揽全局，将 PRD 中的可复用部分，拎取出来，产出 base-prototype.
c-1). 视觉根据 base-prototype，产出 base-mockup.
c-2). 前端根据 base-prototype 和 base-mockup 产出 app-dpl（该项目的 DPL）。
c-3). 交互继续具体页面的 page-prototype 产出工作。
以上三步是并行和迭代进行的。
d-1). 视觉根据 page-prototype 产出 page-mockup.
d-2). 前端根据 page-mockup 产出 page-demo.
以上两步迭代进行。
流程的核心是迭代、是敏捷、是短周期。
最重要的一步是 base-prototype 的产出。交互要避免一个页面一个页面的产出顺序，而应该先有一个统揽全局、拎取通用部分的步骤。
以上流程可以简述为：sys -> app -> page. app 层的抽取很重要，可以提高团队的开发效率和协作程度，让团队更融合、更高效。
感觉 LSM 强调的是前端工程师实现 demo 时的微流程。告诉我们做一个页面时，需要 html 整体 -> 局部模块的 css/js, 逐层开发，先整体后局部，先框架后细节。这是非常好的最佳实践。