前端开发模式

这是一篇讨论前端开发模式的文章。

本文讨论的范围基于以下前提：

1. Web2.0型的网站（偏重设计的网站不在讨论之列）

2. 规模大到中的网站

 

首先我们来看看一个常见的工作流程：

 

需求 > 设计 > 页面 > 后台集成

 

通常需求不关前端开发的事情，但在这个注重用户体验的年代，前端开发也会介入其中讨论一些需求的实现模式。

需求基本确定后一般会提供若干需求文档，以我所在开发团队为例，有一份DOC格式的需求说明书，一份VS格式的页面原型。

在正常情况下，这个时候后台开发会开始进行系统设计，视觉设计师会设计网站的视觉系统和以此为基础的单个页面设计，前端呢 ，额，在一开始的时候，我只准备一些常用代码，基本上处于无所事事的状态。但经过一些探索和大量实践以后，我认为在这个阶段，前端可以做更多的事情：

1. 准备前端基础代码框架，template.html, reset.css, grids.css我相信这些文件大家都不会陌生。

2.  根据页面原型出html，这是比较大胆的一步，也存在一定风险，因为很多人都会有这样的经验：设计师在根据页面原型做完设计后，html代码需要做很大的冗余来实现某些特殊的设计，因此在这个时候，写html页面无异于浪费——你不得不在设计完成后再做一次大的调整。

但，在强调web标准化的时代，局面有很大改观。

首先，设计师们能够理解应用型网站在设计上的特点：绚丽的外表肯定不是最重要的，这个头衔应该挂在规范化和易于实现上（如果你还在为你们的设计师的天马行空头疼，那么你应该跟你们的设计主管聊聊了）。

其次，围绕语义的html代码能够在很大程度上帮助你减小返工的可能性：除非需求做了更改，设计的变更对html的影响应该是比较小的。结构和表现分离，这其实是CSS的初衷，但在早期开发者们并不能很好地把握这其中的界线。

在这种情况下，我们可以根据良好的语义和带表现冗余的结构代码编写这份html，请注意：如果是在一个项目中期或者是有样式基础的二次开发，那么你手头上肯定会有一些早期积累的html/CSS模块代码，其中最抽象、最大复用性的也就是你现在所能依赖的东西。但如果是一个完全崭新的项目，那么恐怕要等稍微迟一点，视觉设计标准出来以后再进行编码会更合适一些。这里所指的视觉设计标准一般是一份样式规范，定义了网站中最主要、最频繁使用的样式，根据这份规范，前端开发人员可以设计合适的全局(global)级别和模块(module)级别的代码，并做适当的抽象和模块化。

 

那么这时候，我们已经完成了一些html页面，如果后台进度良好的话，那么此时可以做一些页面集成——可能这个时候页面设计还没有完成，但没关系，后台通常不关心这个，我们已经提供了后台集成需要的元素：一份内容完整的html页面，这里要注意一点，如果核心功能（跟业务流程相关的）中需要前端脚本代码，那么你也得提前准备好：这在Ajax泛滥的今天非常多见。

因为提前做了集成，那么你接下来的工作会在集成好的系统上进行：也就是说前端开发人员需要在他们的机器上部署整个工程，在某些开发团队里，这种模式是不被接受的，这样增加了维护成本和风险，前端开发人员会碰到各种各样的后台系统带来的问题，这些问题都需要后台开发者抽时间来帮他们解决；另外前端也可能不小心动了后端的一些代码而造成问题。

但好处呢：

一、能够在第一时间发现集成暴露的问题，增大BUG的暴光机会，减少后期的修复成本，我们知道，一个BUG，越晚发现，修复它的成本就越大。

二、工程能随时被发布和预览（我承认这是敏捷的好处）。

三、让后台开发人员的集成能力更专业——前端开发会更快地指出后者的错误。这一点可能跟人员的能力有很大关系，但在现在这个前端日新月异的大环境下，很难说后台开发能很好地把握集成的种种细节。

当具体的设计给出以后，我们开始为页面写CSS和scripts，因为整个流程的缘故，我们能很好地分离内容和表现，某些一直被强调的概念：如无侵入式的脚本，也有了实施的机会。

 

在做了这样一个改进以后，流程变成了：

 

需求 > html > 集成 > CSS&Scripts

       > 设计

 

前端开发的任务被更好地分解和平摊了。我相信很多前端开发者都有过时间太紧，不得不加班赶工的经历，试一下这个流程，能给你的开发带来一些改观。

 

 

---

 

 

 

接下来讲讲开发。

很多前端开发者在做了一段时间后，对页面结构会有一种似曾相识的感觉：是的，表现是如此繁复多样，但它们的“骨子”却如此的相近：head, body, foot, sidebar, nav, box...

这就是我们抽象的机会，这里举一个经典的结构例子：

 

box：

<div class="box"> <div class="hd"><h2>title here</h2><div class="extra"></div></div> <div class="bd"> content here </div> <div class="ft"></div> </div> 

如果要投票的话，这大概是用的最多的一种html结构。box无处不在，设计师会为它们设计多种色系，我们所要做的，就是为不同的表现类别准备对应的class，关于class有一点需要说明的是：在强调语义化的开发，我们会被教导以类名要跟内容联系在一起，而不是表现形式：因为表现易变，不知道什么时候，你的代码中就会出现一个有red类名的box，却是绿色的。这是一个很正确的思路，但在实践过程中，我更推荐这种写法：box_t(N)，其中t代表template。这是从YUI的grids.css中借鉴来的思路，你可以在注释中说明这个类的特征和用途，如果这种样式被废弃，那么你只要简单地重新写一个box_t(N+1)，然后用查找替换把class更改过来；还有一个好处是，你不用费尽心机地去考虑起一个什么名字会比较漂亮（这对很多纠结于细节的人是一种解脱）。

这是一个跨项目的经典结构，其实在一个大型项目下（我们的讨论范畴更接近这种情况），我们会做更低层次的抽象，这些结构的“作用域”是项目内部的。在有了这么多可复用的代码之后，构造一个html页面变得惬意了：我们可以更专注于页面内容的梳理，这才是html的核心。

to be continue...