前端开发的流程与规范

先仍2篇网上找的:

在团队不断成长的过程中，需要处理的需求也在逐渐增长，团队中成员如何分工配合决定了开发的效率、产品的质量，在这个时候我们就需要一个流程来规范、指导我们，下面就将咱们前端组的一些经验跟大家分享一下，有不足之处欢迎大家指出来。

 

        当PRD确立下来后，前端组的同学们就需要做好准备，好应对高强度的开发工作。在今年年初的时候前端组经过激烈的讨论针对新产品的开发做了一些约定。制定了前端开发的一些相关的规范，包括不同产品的命名规范，前端文件存放目录等等一系列的前期准备。别看这些只是小事，但做好万全的准备，是敏捷开发中所必的。

 

下面讲讲前端开发组的流程。

 

1、分层开发

 

        在PRD确定后就需要进行分层开发的划分，根据项目内容的不同，划分组员的工作。大致分为，总体结构搭建、模块制作、页面制作、底层JS搭建、JS交互效果、内部测试、代码优化。

 

        这样做的好处是能根据项目的不同，划分出不同的功能模块，合理的进行人员分配，让合适的人做合适的事。降低开发成本，提高开发效率。

 

 

2、代码编写

 

        前期工作准备好后，就开始进入代码编写阶段，我们采用LSM方式进行，大致流程为 prototype产出后，就进行前期的前端开发（搭建大致的HTML结构），然后设计出完设计稿后再进行页面样式的完善，最后完成正式的页面后交给开发，嵌套程序。这样做的好处不仅能有效的提高开发效率，实现逐层开发，让前端提前介入，减少整体消耗的时间，确保产品有更多的时间修改和完善。

 

        确定了流程后还需要对产品原型进行分析、拆分，把复用性高的部分找出来制作成代码模块，方便以后的套用。确认二、三级页面的风格搭建统一框架。

 

        设计拿到prototype后，就进行通用模块样式的设计（包括按钮、分页、默认字体颜色、连接颜色等），完成后并提交给前端，统一的搭建。

 

        在代码的编写过程中，最重要的是标准和规范的执行遵守，在编写HTML时候充分发挥想象尽可能的满足后期样式表现的需要。

        代码编写过程中让前端组提前进入开发流程中来，在prototype产出后就进行HTML结构的编写，页面设计完成后，在进行样式表的开发，这样不仅能节省很多的开发时间，提高开发效率，还能锻炼前端组的同学对全局页面的把控。在此同时也强调规范和模块化的重要性，正所谓无规矩不成方圆，在一个团队协同开发过程中，必须要严格按照规范执行，这样能便于后期维护，减少维护成本。而模块化，是敏捷开发所必需的，重要性在这里也不做过多的描述。

 

 

3、内部测试与后续优化

 

        所有页面出完以后设计参与前端组的内部测试，指出页面与设计稿不匹配的地方，优化部分细节页面样式。让设计参与测试不仅能提高内测的质量，还能更早的发现问题并及时的修改，否则当页面提交开发以后再做修改是一件很麻烦的事情。当所有细节修改完毕后，就需要进行制作文件的优化以确保代码的最优化，尽可能地压缩图片和减少外部HTTP请求。

 

总的流程结构图

        这套流程制定出来就一直要求所有前端组同学严格按照流程执行，也经过了很长时间的磨合跟改进。虽然不是很完美，但是很适合我们现在开发的需要，好处也是显而易见的，遵循并使用它对我们的发开有很大的帮助，能更好的应对高强度，高质量的开发需要。提高了团队的协作程度，代码更可控，开发效率更高。

 

=======================================================================================

我的理解

传统方式：产品经理产出 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, 逐层开发，先整体后局部，先框架后细节。这是非常好的最佳实践。