在这个用户体验为王的Web 2.0时代，Web应用所涉及的领域越来越广，规模越来越大，需求越来越多样化和复杂化，更新的速度也越来越快。如何才能让我们的应用应对规模化、多样化、复杂化和快速变化带来的种种问题？编写高质量的、易于维护的Web前端代码似乎是解决这些问题的唯一途径。
如何才能编写出高质量的、易于维护的Web前端代码？本书的主要内容围绕Web前端开发的三大技术要素——HTML、CSS和JavaScript展开，深入地讨论了编写高质量的HTML代码、CSS代码和JavaScript代码的方法、技巧、规范和最佳实践，从而为编写易于维护的Web前端代码打下坚实的基础。希望《编写高质量代码--Web前端开发修炼之道》能帮助大家从一筹莫展的前端维护工作中走出，从此微笑地面对需求的“变化”。

作者简介：
曹刘阳，网名阿当，资深Web前端开发工程师，先后就职于中国雅虎和淘宝，现就职于新浪，一直从事Web前端开发工作，实战经验非常丰富，在通过提高代码质量来增强可维护性方面颇有心得。精通HTML、CSS、JavaScript等前端开发技术，对ActionScript、Flex、PHP、RoR等Web开发技术也有较深入的研究。致力于敏捷开发实践，喜欢读书，阅读过大量技术书籍；擅于总结归纳，能将各种技术融会贯通。

本书配套源代码下载：http://dl.iteye.com/topics/download/d2214dc4-3588-3edd-ad12-38b971cabd31

    Web前端开发是从网页制作演变而来的，名称上有很明显的时代特征。在互联网的演化进程中，网页制作是Web 1.0时代的产物，那时网站的主要内容都是静态的，用户使用网站的行为也以浏览为主。2005年以后，互联网进入Web 2.0时代，各种类似桌面软件的Web应用大量涌现，网站的前端由此发生了翻天覆地的变化。网页不再只是承载单一的文字和图片，各种富媒体让网页的内容更加生动，网页上软件化的交互形式为用户提供了更好的使用体验，这些都是基于前端技术实现的。
    以前会Photoshop和Dreamweaver就可以制作网页，现在只掌握这些已经远远不够了。无论是开发难度上，还是开发方式上，现在的网页制作都更接近传统的网站后台开发，所以现在不再叫网页制作，而是叫Web前端开发。Web前端开发在产品开发环节中的作用变得越来越重要，而且需要专业的前端工程师才能做好，这方面的专业人才近两年来备受青睐。Web前端开发是一项很特殊的工作，涵盖的知识面非常广，既有具体的技术，又有抽象的理念。简单地说，它的主要职能就是把网站的界面更好地呈现给用户。
如何才能做得更好呢？
    第一，必须掌握基本的Web前端开发技术，其中包括：CSS、HTML、DOM、BOM、Ajax、JavaScript等，在掌握这些技术的同时，还要清楚地了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug。
    第二，在一名合格的前端工程师的知识结构中，网站性能优化、SEO和服务器端的基础知识也是必须掌握的。
    第三，必须学会运用各种工具进行辅助开发。
    第四，除了要掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持，等等。
    可见，看似简单的网页制作，如果要做得更好、更专业，真的是不简单。这就是前端开发的特点，也是让很多人困惑的原因。如此繁杂的知识体系让新手学习起来无从下手，对于老手来说，也时常不知道下一步该学什么。
    目前市面上关于Web前端开发的书主要都是针对单一技术的，本书与这些书有着本质的区别。它主要想实现两个目标：第一，为不太有经验的Web前端开发工程师建立大局观，让他们真正了解和理解这个职业；第二，帮助有一定Web前端开发经验的工程师修炼内功，通过编写高质量的代码来提高前端代码的可维护性。这是很多前端开发工程师感兴趣的内容。
    本书的前两章讨论了网站重构和团队合作，这是很有必要的。网站重构的目的仅仅是为了让网页更符合Web标准吗？不是！重构的本质应该是构建一个前端灵活的MVC框架，即HTML作为信息模型（Model），CSS控制样式（View），JavaScript负责调度数据和实现某种展现逻辑（Controller）。同时，代码需要具有很好的复用性和可维护性。这是高效率、高质量开发以及协作开发的基础。建立了这种大局观后，学习具体技术的思路就更清晰了。
    代码质量是前端开发中应该重点考虑的问题之一。例如，实现一个网站界面可能会有无数种方案，但有些方案的维护成本会比较高，有些方案会存在性能问题，而有些方案则更易于维护，而且性能也比较好。这里的关键影响因素就是代码质量。CSS、HTML、JavaScript这三种前端开发语言的特点是不同的，对代码质量的要求也不同，但它们之间又有着千丝万缕的联系。本书中包含着很多开发的思想和经验，都是在长期的开发实践中积累下来的，不同水平的Web前端工程师都会从中获得启发。

张克军（著名Web前端开发工程师）
2010年4月

    前端开发工程师是一个很新的职业，在国内乃至国际上真正开始受到重视的时间不超过5年。但是，随着Web 2.0概念的普及和W3C组织的推广，网站重构的影响力正以惊人的速度增长。XHTML+CSS布局、DHTML和Ajax像一阵旋风，铺天盖地席卷而来，包括新浪、搜狐、网易、腾讯、淘宝等在内的各种规模的IT企业都对自己的网站进行了重构。
    为什么它们会对自己的网站进行重构呢？有两个方面的原因：
    第一，根据W3C标准进行重构后，可以让前端的代码组织更有序，显著改善网站的性能，还能提高可维护性，对搜索引擎也更友好；
    第二，重构后的网站能带来更好的用户体验，用XHTML+CSS重新布局后的页面，文件更小，下载速度更快。
    DHTML可以让用户的操作更炫，更吸引眼球；Ajax可以实现无刷新的数据交换，让用户的操作更流畅。对于普通用户来说，一个网站是否专业、功能是否强大，服务器端是用J2EE+Oracle的强大组合，还是用ASP+Access的简单组合，并没有太明显的区别。但是，前端的用户体验却给了用户直观的印象。
    随着人们对用户体验的要求越来越高，前端开发的技术难度越来越大，前端开发工程师这一职业终于从设计和制作不分的局面中独立出来。前端开发技术包括三个要素：HTML、CSS和JavaScript，但随着RIA的流行和普及，Flash/Flex、Silverlight、XML和服务器端语言也是前端开发工程师应该掌握的。前端开发工程师既要与上游的交互设计师、视觉设计师和产品经理沟通，又要与下游的服务器端工程师沟通，需要掌握的技能非常多。这就从知识的广度上对前端开发工程师提出了要求。如果要精于前端开发这一行，也许要先精十行。然而，全才总是少有的。所以，对于不太重要的知识，我们只需要“通”即可。但“通”到什么程度才算够用呢？对于很多初级前端开发工程师来说，这个问题是非常令人迷惑的。
    前端开发的门槛其实非常低，与服务器端语言先慢后快的学习曲线相比，前端开发的学习曲线是先快后慢。所以，对于从事IT工作的人来说，前端开发是个不错的切入点。也正因为如此，前端开发领域有很多自学成“才”的同行，但大多数人都停留在会用的阶段，因为后面的学习曲线越来越陡峭，每前进一步都很难。另一方面，正如前面所说，前端开发是个非常新的职业，对一些规范和最佳实践的研究都处于探索阶段。总有新的灵感和技术不时闪现出来，例如CSS sprite、负边距布局、栅格布局等；各种JavaScript框架层出不穷，为整个前端开发领域注入了巨大的活力；浏览器大战也越来越白热化，跨浏览器兼容方案依然是五花八门。为了满足“高可维护性”的需要，我们需要更深入、更系统地去掌握前端知识，这样才可能创建一个好的前端架构，保证代码的质量。
    一位好的前端开发工程师在知识体系上既要有广度，又要有深度，所以很多大公司即使出高薪也很难招聘到理想的前端开发工程师。市面上有很多关于前端开发的书，这些书籍能很好地指导读者掌握前端开发的基础知识，能让读者达到会用的水平。然而，几乎还没有书能告诉开发者们如何才能用得更好，如何才能编写出高质量的前端代码，如何才能系统有效地组织前端架构……本书弥补了这方面的市场空白，它假定读者已经具有一定的Web前端开发基础，不会对基础知识进行详细介绍，主要精力放在如何编写和组织高质量代码上，从而提高代码的可维护性。
    本书的重点不在于讲解技术，而是更侧重于对技巧的讲解。技术非黑即白，只有对和错，而技巧则见仁见智。本书是笔者个人的经验分享，尽信书不如无书，大家可以有选择地吸收，如果对书中的观点或技巧有不同的见解，非常欢迎与笔者讨论交流。大家可以通过邮箱cly84920@gmail.com与作者取得联系。
    在编写本书的过程中，如何组织目录一直是让笔者非常纠结的事情：HTML、CSS和JavaScript是三门截然不同的语言，在实际应用过程中涉及的深度也各不相同，HTML需注意的事项较少，CSS次之，JavaScript最为复杂。所以，本书虽然会同时对这三个方面进行探讨，但所用篇幅与它们的复杂度是成正比的。

本章内容

•    糟糕的页面实现，头疼的维护工作
•    Web标准--结构、样式和行为的分离
•    前端的现状
•    打造高品质的前端代码，提前代码的可维护性--精简、重用、有序

    从1989年诞生至今，网页技术已有20年历史了，其用途由最初的纯学术交流，延伸到如今的门户网站、电子商务网站、博客、邮箱、Web Game、SNS、维基百科等，涉及我们的工作、生活、学习和娱乐的方方面面。互联网世界有数以万亿计的网页，负责承载和展示信息。
    事实上，制作网页并不难，只要有一个文本编辑器，买本入门书，几分钟就可以动手做出一个简单的网页来。但是，要做一个好的网页，却不是一件容易的事情。任何一个有经验的工程师都知道，工作中的最大考验和最不可回避的问题就是“变化”。我们在制作网页的时候，不仅要实现需求，更重要的是要考虑实现代码的可维护性，为未来可能出现的“变化”提前做好准备。
    先来看一个可维护性不好的网页实现案例，实现过程如代码清单1-1所示，这是一个历史有点悠久的老网页，几乎有着所有老网页都有的典型毛病。

代码清单1-1  一个糟糕的老网页的实现
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type=text/css>
td,body {  font-size: 15px; font-family:arial,sans-serif,宋体;}
body{margin-top:0px;margin-left:0px;margin-right:0px;background-color:#fcfff7}
a:link{ color:#000000; text-decoration:none;padding-left:4px; }    
a:visited{COLOR: #000000; TEXT-DECORATION: none;padding-left:4px;}
a:active{color:green;text-decoration:none;padding-left:4px;}
a:hover{color:red;text-decoration:underline;padding-left:4px;}
a.m:link{ color:#000000; text-decoration:none;padding-left:0px;}
a.m:visited{COLOR: #000000; TEXT-DECORATION: none;padding-left:0px;}
a.m:active{color:green;text-decoration:none;padding-left:0px;}
a.m:hover{color:red;text-decoration:underline;padding-left:0px;}
.t1{border-width:1px 1px 1px 1px;border-style:solid;font-size:12px;
text-align:center}
.bgg{border-color:#8AB78A; width:779px}
.f9pt{font-size: 12px;}
#sfont a,#sfont b{font-size:13px;}
</style>
<base target="_blank">
<title>网址之家－－动漫</title>
<script src="js/usertrack.js"></script>
</head>
<body>
<div align="center"><center>
<table border="0" cellpadding="0" cellspacing="0" width="778" height="51">
    <tr>
      <td width="230" height="51"><a href="http://www.xxx.com" target="
_self" class="m"><img src="logo.gif" alt="xxx.com" width="168" height=
"63" border="0"></a></td>
     <td height="51" align="center"><table width="100%"border=0 cellpadding=
     0 cellspacing=0>
        <form name=form1 action=http://www.baidu.com/s>
<input type=hidden name=tn value=abc>
<tr>
        <td colspan="2" id=sfont>　
<a  href=http://news.baidu.com>新 闻</a>  
<b>网 页</b>  
<a  href=http://tieba.baidu.com>贴 吧</a>  
<a  href=http://zhidao.baidu.com>知 道</a>  
</td>
      </tr>
<tr>
<td height="30" valign="top">　
<input type=text name=wd size=40 onMouseOver=this.focus()
onFocus=this.select() style="margin-bottom:-5px; font-size:
16px;height:1.78em;font-family:arial,sans-serif,宋体;padding-
top:2px; padding-left:1px" maxlength=100>
<input type=submit style="height:1.82em;width:6.4em;font-size:
    16px; margin-bottom:-5px; padding-top:2px" value="百度一下">
</td>
     <td width="80" valign="top" class="f9pt"> </td>
</tr>
     </form></table></td>
</tr>
  </table>
</center></div>
<script language=javascript>
<!--
UserTrack.init(1,"动漫")
document.form1.wd.focus()
//-->
</script>
</body>
</html>

    这个页面的实现代码都有哪些地方不利于维护呢？

•   div布局和table布局混用；
•   标签名有大写的，也有小写的；
•   标签属性有的加了引号，有的没有加引号；
•   历史遗留的、被淘汰的属性泛滥；
•   样式组织混乱，有用<style>标签写进网页里的，有用<link>外链的，也有直接写在标签内的；
•   JavaScript有外链的，有写在<scirpt>标签内的，也有写在标签里的；
•   JavaScript和CSS的位置零乱；
•   JavaScript的编码风格很不一致；
•   无论是JavaScript代码还是CSS代码，都看不到任何注释；

……
    这是一段非常典型的网页代码，毫无章法，结构（HTML）、样式（CSS）和行为（JavaScript）非常混乱地耦合着，在网站重构这场革命以前，大多数的网页都有这些毛病。维护这样的网页难度非常大，成本自然也非常高。
那么，如何组织网页代码才算是有章法呢？说到这个问题，就不得不提Web标准，它是网站重构的基础。

W3C是一个专门负责制定网页标准的非营利性组织，致力于结束网页制作领域混乱不堪的局面，Web标准就是由W3C组织推行的。要了解最权威、最详细的关于Web标准的信息，可以访问其官方网站：http://www.w3c.org。

Web标准由一系列标准组合而成，其核心理念就是将网页的结构、样式和行为分离开来，所以它可以分为三大部分：结构标准、样式标准和行为标准。结构标准包括XML标准、XHTML标准、HTML标准；样式标准主要是指CSS标准；行为标准主要包括DOM标准和ECMAScript标准。

一个符合标准的网页，标签中的标签名应该全部都是小写的，属性要加上引号，样式和行为不再夹杂在标签中，而应该分别单独存放在样式文件和脚本文件中。理想状态下，网页源代码由三部分组成：.html文件、.css文件和.js文件。标签中混有样式和行为的写法是不推荐的，如代码清单1-2所示。

代码清单1-2  结构、样式和行为混杂的网页实现
<td width="100%" height="20"  class="f9pt"  align="center">
<font color="#346F0E">下载</font>
<input type=text name=wd size=40 onMouseOver=this.focus() onFocus=
this.select()style="margin-bottom:-5px;font-size:16px; height:1.78em;
font-family:arial,sans-serif,宋体;padding-top:2px; padding-left:
1px" maxlength=100>
</td>

这种段代码应该改成下面这样的形式，如代码清单1-3所示。
代码清单1-3  结构、样式和行为单独分开的网页实现
test.html文件：
<link rel="stylesheet" type="text/css" href="test.css" />
<td class="f9pt myTd">
<span class="myFont">下载</span>
<input type="text" name="wd" size="40" id="myInput"maxlength="100" />
</td>
<script type="text/Javascript" src="test.js"></script>

==============================================================
test.css文件：
.myTd{width:100%;height:20px;text-align:center;}
.myFont{color:#346F0E;}
#myInput{margin-bottom:-5px;font-size:16px;height:1.78em;font-family: arial,sans-serif,宋体;padding-top:2px;padding-left:1px}
==============================================================

test.js文件
var myInput = document.getElementById("myInput");
myInput.onmouseover = function(){
   this.focus();
}
myInput.onfocus = function(){
   this.select();
}

如此一来，原来混乱不堪的HTML变得清爽多了。HTML标签只用负责承载内容，而样式交给了CSS，行为交给了JavaScript。
将结构、样式和行为分成三个文件，这是比较推荐的做法。但事实上，我们在工作中经常会因为各种原因而仍然把样式和行为放在.html文件中。即使是在这样的情况下，仍然可以将样式和行为从标签中分离出来，如代码清单1-4所示。
代码清单1-4  将样式和行为从标签内分离开
<style type="text/CSS">
.myTd{width:100%;height:20px;text-align:center;}
.myFont{color:#346F0E;}
#myInput{margin-bottom:-5px;font-size:16px;height:1.78em;font-family: arial,sans-serif,宋体;padding-top:2px;padding-left:1px}
</style>
<td class="f9pt myTd"><span class="myFont">下载</span><input type= "text" name="wd" size="40" id="myInput" maxlength="100" /></td>
<script type="text/Javascript">
var myInput = document.getElementById("myInput");
myInput.onmouseover = function(){
   this.focus();
}
myInput.onfocus = function(){
   this.select();
}
</script>

如果不将CSS和JavaScript作为独立文件外链出去，而是在HTML页面里用<style>和<script>标签来承载样式和行为也是可以的，只要不在HTML标签上书写样式和行为，仍然实现了结构、样式和行为的分离。代码的职能已经非常非常清晰了，只是没有分开成三个文件而已。
但是，仅仅将结构、样式和行为分离开就可以带来足够好的可维护性吗？不，这仅仅只是个开始。

这几年来，Web开发技术发展十分迅速。随着《网站重构》一书的问世，CSS布局代替传统table布局之风迅速刮起，国内外大大小小的网站都纷纷加入到这场技术革命中。Gmail的上线，让Ajax一夜之间成为了Web开发领域的明星。之后，随着Ajax的火热，DHTML再次受到热捧，各种JavaScript框架如雨后春笋般涌现出来，让人应接不暇。

这种发展变化是一把双刃剑，一方面它使得网页的表现力越来越强，我们可以用网页做出惊艳的效果；另一方面，漂亮的界面背后隐藏着的是越来越难维护的实现代码。为什么网页的维护工作会变得越来越难？原因主要来自三个层面：

•   浏览器层面。浏览器的向前兼容使得前端开发中被淘汰的技术、不推荐的方法依然广为流传和应用，而新一轮的浏览器大战却愈演愈烈，除了Firefox、Opera、Safari、Chrome这些IE的挑战者外，IE本身也同时流行着IE 6一、IE 7和IE 8三个不同的版本。不同的浏览器对网页代码的解析存在着或大或小的差异。
•   技术层面。Web标准被重视和普遍采用的时间不长，整个大环境对Web标准的理解还停留在概念层面，对“好的实现方案”仍处于摸索阶段。不同的公司，不同的团队，不同的工程师，对“好的实现方案”有自己的理解，或深或浅。理解不深，就很容易写出可维护性差的代码。
•   团队合作层面。随着用户对使用体验的要求的不断增加，对网页的表现力的要求也越来越高，从而导致实现代码越来越复杂，这无疑给团队合作带来了麻烦。页面越复杂，对团队合作的要求就越高。如果合作不默契，很可能需要不停地打补丁，最后让代码变得千疮百孔，满是地“雷”，没有人愿意去维护它们。

随着维护难度的增加，网页制作对技术的要求越来越高，Web开发领域长期以来形成的设计和制作不分的局面终于有所好转。细心的朋友可能会发现，在51job这样的招聘网站上，前两年几乎只有“网页设计师”这个职位，而现在已经有了前端开发工程师和页面工程师二这样的职位。之前既要负责设计又要负责制作的网页设计师，已经分离成了两个岗位：一个专门负责设计，属于艺术类；另一个专门负责制作，属于技术类。这是一个可喜的变化，设计师（designer）和开发者（developer）本来就是两个完全不同的方向，将两者明确分开，表示网页制作的分工向着合理成熟的方向又迈出了一大步。专注于网页制作的技术方向，有了更专业的叫法——“前端开发”。

相比于服务器端开发曲折陡峭的学习曲线，前端开发的学习曲线平滑得多。正因为前端开发上手快、门槛低，所以非常多的人通过自学成才，从这一方向进入IT领域。也正因为如此，这一领域的大多数技术人员并没有比较系统的知识结构和良好的编码习惯。虽然有Web标准的概念，但往往并没有一个很好的实践方案。并不是结构、样式和行为分离了就完了，如何在多人合作时做到有条不紊、如何让代码的可维护性更好等这些“实践”性的技巧往往比Web标准本身更重要。如果重理论，而忽视了实践，那么代码的质量依然很难得到提高。

然而，什么样的代码算是高品质的代码呢？

所谓高质量的代码，在Web标准的思想指导下，在实现结构、样式和行为分离的基础上，还要做到三点：精简、重用、有序。精简的代码可以让文件变小，有利于客户端快速下载；重用可以让代码更易于精简，同时有助于提升开发速度；有序可以让我们更清晰地组织代码，使代码易于维护，有效应对变化。

Web标准是一套理论性的指导思想，它的最终目的是让代码更易于维护，标准本身是手段，而不是目的。在应用Web标准的实践中，有时候不遵循标准反而能带来更好的可维护性，如果你确信你的方案利大于弊，那么就去做吧，尽信标准不如无标准，过于教条主义是一件很愚蠢的事情。

本章内容

•    揭秘前端开发工程师
•    欲精一行，必选通十行
•    增加代码可读性—注释
•    提高重用性—公共组件和私有组件的维护
•    冗余和精简的矛盾—选择集中还是选择分散
•    磨刀不误砍柴工—前期的构思很重要
•    制订规范
•    团队合作的最大难度不是技术，是人

本章主要探讨团队合作的注意事项，在正式讲解如何进行团队合作之前，先让我们了解什么是前端开发工程师。

前端开发工程师是一个新兴的职业，关于它的职能定位，包括很多同行在内，都比较模糊。下面结合一些互联网公司对前端开发工程师的招聘要求来看一下这个职位到底需要具备哪些技能和素质。

下面是盛大公司的一则招聘中对前端开发工程师的要求：
1. 绝对熟练 div+CSS 制作方式，对网页标准有独特的见解；
2. 精通XHTML \ CSS \ JavaScript，熟练使用 JavaScript 前端脚本，要有常用效果和功能的积累。会用常见的JavaScript类库，如jQuery 或Mootools等 。理解异步请求原理，可以配合程序员开发一些简单的Ajax应用。
3. 至少了解一门后台语言，例如PHP或ASP.NET。
4. 熟练使用网页设计相关的软件。
5. 两年以上团队协作开发经验，有责任心、爱钻研、爱思考。
6. 具有本科及以上学历。

从前端开发工程师的角度来解读这则招聘中的要求，我们可以得出如下结论：
第一：CSS布局是前端开发工程师的基本功，一定要熟练。这点我十分赞同，因为前端开发工程师的本职工作就是制作网页。在前端开发工程师的日常工作中，CSS的使用比重占到了所有技能的50%～70%，有些公司可能更高。所以，有些公司在招前端开发工程师时甚至只要求会用CSS。对于CSS，最基本的要求就是能兼容主流浏览器—IE 6、IE 7、IE 8和Firefox，有些公司可能还会要求兼容Opera、Safari、Chrome。
第二：对JavaScript的使用有所要求，不仅要会使用原生的JavaScript，还要会使用JavaScript类库和Ajax。在这个用户体验至上的时代，网页已经不再只是内容的承载体，只负责简单地显示页面内容，现在的网页不仅要求能吸引眼球，而且还要为用户提供良好的交互体验。

这里提到了三个概念：原生JavaScript、JavaScript类库和Ajax，有些刚从事前端开发工作的朋友可能不太明白它们三者之间的区别，本书略微解释一下。

原生JavaScript是浏览器默认支持的脚本语言，Ajax是一种利用JavaScript和XMLHttpRequest对象在客户端和服务器端传送数据的技术，因为XMLHttpRequest对象也是用JavaScript来创建的对象，所以从某种意义上来说，Ajax是JavaScript的一个子集。很多刚进入这个行业的朋友将Ajax和JavaScript并列起来讲，甚至认为Ajax比JavaScript复杂得多。其实这是误解！

事实上，Ajax只是种提交数据的方式，与传统的表单提交方式相比的确有所不同，但其核心内容其实非常少，学习起来并不困难。前端开发中最复杂的技术其实是JavaScript。JavaScript类库又是什么呢？因为浏览器默认支持的JavaScript（我们常称为原生JavaScript）会因浏览器的不同而有所差异，例如IE支持document.all属性，而Firefox不支持。同时，原生JavaScript提供的方法可能并不太好用，比如只提供了document.getElementById和document.getElementsByTagName，却没有提供document.getElementsByClassName。又比如，原生JavaScript并不提供富文本编辑器和拾色器这种复杂的UI工具。基于这些原因，于是出现了JavaScript类库。JavaScript类库是在原生JavaScript的基础上，封装了跨浏览器兼容的特性并扩展了一些功能，提供了一些原生JavaScript没有的API，供开发者快速开发JavaScript程序使用。

第三：前端开发工程师为什么需要了解后台语言呢？需要了解到什么程度呢？这是让很多同行感到迷惑的地方。事实上，前端开发工程师的工作只是制作网页，对于网页中动态生成的内容，也就是来自数据库的内容完全不用关心。前端工程师不必了解系统的数据库设计，不必了解数据在数据库中存取的细节。前端开发工程师之所以需要了解后台语言，主要因为以下三个方面的原因：

•   知道服务器端工程师在生成页面时会如何进行输出，以便编写出方便他们套脚本的模板；
•   在写Ajax应用的时候，可以自己模拟服务器端输出，方便调试；
•   对前端和服务器端如何配合有清晰的大局观认识，了解数据传递的整个流程，以配合工程师共同制定复杂效果的实现方案。

要做到这三点其实并不困难，我们甚至只需要掌握服务器端语言的部分语法就可以了！以PHP为例，只需要知道$、echo、$_REQUEST[]、单引号和双引号的区别、session、cookie即可。我们不需要了解如何使用PHP的高级语法，不需要了解如何配置Apache，甚至完全不需要知道SQL语言。当然，服务器端语言掌握得越深，对我们处理复杂问题越有帮助。

事实上，前端开发工程师并不需要写服务器端语言，之所以对服务器端语言有要求，完全是为了在工作中与服务器端工程师配合默契。所以，前端开发工程师只需要了解服务器端工作原理，会用服务器端语言写输出接口即可。而无论哪种服务器端语言，例如PHP、ASP/ASP.NET、JSP，虽然具体语法有差异，但工作原理大同小异，所以一般公司的招聘要求并不指定具体是哪门语言，只要熟悉任何一门服务器端语言即可。

大家可能注意到，在盛大的这则招聘信息中，Flash并没有被提及！这是因为，随着Web标准的推广，前端开发工程师的本职工作已经重点落到了网页的制作上，网页三要素——结构、样式、行为，也就是HTML、CSS和JavaScript才是前端开发工程师的核心工作，而Flash作为富媒体应用，从前端开发中被分离出来，由专门的Flash开发工程师负责。当然，由于过去将“网页设计师”等同于“网页制作三剑客”的历史原因，前端开发工程师和Flash仍然还是有着剪不断理还乱的关系。虽然Flash已经越来越强大，越来越需要专攻Flash的人来负责开发，但还是有很多人认为Flash应该是前端开发工程师应该掌握的技能，至少是附属技能。可喜的是，持这种观点的人已经越来越少。广义上来讲，富媒体开发也属于前端开发的范畴。

前端开发位于网站开发的中游，上游有交互设计师和视觉设计师，下游有服务器端工程师，前端开发工程师需要与他们沟通，所以需关注的知识面非常广。图2-1一真实地反映了一位前端开发工程师应该关注和掌握的技能。


图2-1  前端开发工程师应该关注的知识领域

很多朋友可能会问了，我只是前端开发工程师，只想要专精一个领域！涉猎面如此之广，真的有必要吗？

将前端开发和服务器端开发做一个比较，前端开发没有服务器端开发“深”，服务器端开发没有前端开发“广”。经常听到做前端的同行抱怨需要学的东西太多，东学一点西学一点，什么都会，但也什么都不精。很直接的结果就是沦为打杂的程序员，对能力没自信，在团队说话也不够有分量。于是越来越多的同行们得出了一个结论：“通十行不如精一行！”

其实这是个误区。精通一行？在前端开发领域，不通十行就无法精一行。

先来说说“精一行”这个很重要的概念吧。具体细化到什么程度叫做“一行”？是具体到前端/服务器端，还是具体到设计/DIV+CSS/JavaScript/RIA？细化的粒度越小，我们需要掌握的也就越少。很多工程师为了能够快速“精”一行，尽量让“一行”的粒度细化。可是，有两个问题：
  精的粒度越小，我们的就业范围就越小。显而易见，如果你精通的范围越小，你的实用价值也就越小。
  这个行业的界限非常不明显，各个领域互相渗透。比如说。你想成为ActionScript 3方面的专家，你选择了走Developer的路。Designer相关的知识可以不用考虑太多。你不用去学配色，不用去学PhotoShop质感处理，不用去学AI，不用去学CD，不用去管用户交互，不用去管版式设计，你只管程序就OK。而且，我只想成为ActionScript 3方面的专家，我只要学好ActionScript，而且是ActionScript 3，ActionScript 2我都可以不用去学，多轻松啊！是吧？真是这样吗？当你决定只去钻这一个方向的时候，你会发现原来ActionScript还要与前台和服务器交互， ActionScript自己不是万能的，它需要与其他程序配合。好吧，那么前端的和后端的你可以不学吗？如果不学，你会发现自己很多时候搞不明白整个流程，你的工作会困难重重。是的，只是知道就可以了，并不需要精。技术与技术之间会互相依赖、交叠和渗透，就算你只想成为一名视觉设计师，如果你不懂div+CSS，你设计的图前端工程们可能很难实现。也就是说，想要做个好的视觉设计师，掌握一些CSS的知识也是必要的。

我们再回到前面的盛大招聘的例子。盛大招聘的前端工程师有些什么要求？前端各种技术该有的都有了，为何还要求会服务器端技术？是它们不懂技术乱提条件吗？相反，是它们懂技术，知道“精一行，得通十行”的道理。它们的招聘岗位又怎么样呢？有细分到 ActionScript 3工程师、jQuery工程师、YUI工程师、PS设计师、AI设计师吗？没有，分工如此细的岗位是不存在的。没办法，只专精一个极细领域的岗位的需求是极少的，我们不得不选择“粗粒度”的精，也就是说，不必精十行，至少要通十行。

专精很难，甚至不可能，一专多能才是现实的。在前端开发这个领域，一专多能更是非常必要的。

知道了什么是前端开发工程师，那么接下来讲讲前端开发工程师的团队合作需要注意些什么问题。

我们的开发过程，很可能是需要多人合作完成的。大体来说，可以分成两种情况：一种是事先商量好，有组织有计划的分工合作，我们称其为“直接团队合作”好了；另一种是事先并没有考虑到的，因为种种原因而导致你去维护他人开发过的系统，我们称其为“间接团队合作”。

不要断定你现在编写的代码，将来一定不会有其他人来维护，“间接团队合作”常常是出乎意料的！就算你十分确定这代码只可能由你自己来维护，也一定要做好“间接团队合作”的准备，因为哪怕是你自己写的代码，3个月之后你再来看它，一样会觉得它十分陌生！

无论是“直接团队合作”还是“间接团队合作”，一个保证代码可读性良好的绝佳武器就是注释。关于注释甚至有一种说法：“一个好的代码，注释要占1/3的篇幅”。虽然有些夸张了点，不过它表明了注释的重要性。

团队合作很容易产生的问题之一就是冗余。如果没有事先做好规划，很容易出现这样一种情况：工程师甲在页面A上为了实现某种效果写了一段代码，工程师乙在页面B上遇到同样的问题时又重写了一遍。如果系统升级，这个效果需要改变，那么工程师甲和工程师乙都需要更改这部分代码，明显是一种资源浪费。

避免出现这种冗余的最好办法就是根据代码的重用度，把它们分成公共组件和私有组件两类。设计公共组件时需要考虑让接口保持弹性，并且高度模块化，这是很考验能力和经验的工作。关于前端开发的公共组件和私有组件的设计细节详见4.2节和5.2节。

因为公共组件在设计之初就是考虑到要被多人多处重复使用的，如果公共组件一旦被修改会造成很大影响！所以我们需要对公共组件的稳定性保持高度警惕，不允许轻易做修改。一般来说，公共组件对于绝大多数人只提供“读”的权限，不允许它们进行修改，只对少数公共组件的维护者提供“写”的权限。关于“读”和“写”的权限问题，可以通过相关软件实现，例如svn，也可以通过“规范”的形式对团队成员进行约定。

一般来说，公共组件需要由专人来维护。负责维护公共组件的工程师需要将公共组件做好注释，必要时甚至需要提供规范的API文档和演示Demo。其他工程师在工作中如果遇到需要高度重用的模块，而公共组件中尚未提供，可以向维护公共组件的工程师提交需求，让他来添加相应的公共组件。

私有组件因为不考虑其他人重用的问题，所以对于修改操作会自由得多。但不要忘记，虽然你的私有组件不会被他人重用，但仍然可能会被他人维护，所以必要的注释还是需要的。

有了公共组件和私有组件的区分，可以有效避免代码的重复。但又会带来新的问题——如何组织公共组件。

一般来说，合理的前端架构中CSS和JavaScript都是会提取公共组件的，如何组织公共组件是需要权衡的。如果没有将公共组件载入到系统中，那么组件是没法被使用的。一个最方便的做法就是将公共组件全部打包好，然后一次性全部载入，这样可以保证所有的组件都是可用的。这种做法的好处是加载方便，但加载的代码量可能过大，而很多代码事实上很可能是没有被用到的。另一种做法是将代码精确划分成一小块一小块，然后按需加载相应的模块。这种做法的好处是加载灵活，保证代码的加载量小，但坏处是使用起来比较麻烦。

我们在组织公共组件时，组织的粒度越大，文件越集中，加载和管理越方便，但无用代码越多；组织的粒度越小，文件越分散，加载和管理越麻烦，但无用代码越少。我们要加载方便就要适当舍弃精简性，要保证精简性就要适当放弃加载的方便性。我们需要认识到一点：完美的解决方案是不存在的，我们只能在冗余和精简中尽量找到最佳的平衡点。

以JavaScript为例，拿最流行的两个JavaScript框架jQuery和YUI来说，jQuery就选择了“集中”，而YUI选择了“分散”。jQuery将所有组件全放在了一个文件中，但它通过非常优秀甚至诡异的算法，让代码本身尽可能精简，从而尽量让代码在“加载和使用方便”的基础上，尽量往“精简”靠拢。而YUI将组件按功能分成了一个个不同的文件，在页面中只根据需求加载相关的文件。YUI通过智能的loader方式，尽可能让这种按需加载对用户友好。YUI在保证“精简”的基础上，尽量往“加载和使用方便”靠拢。两者出发点不同，但都找到了一个不错的平衡点。

我个人更偏向YUI的按需加载方式，因为这样的方式扩展性更好。jQuery之所以成功，和js的原生API比较少有直接关系，jQuery提供的为数不多的API已经基本能够满足我们日常开发的绝大部分需求。但这种情况并不适用于所有的语言，比如API数量庞大的as和java。“import”这种按需加载的方式才是真正的主流。

因为公共组件是预写好的，弹性才是它们最应该重点考虑的，毕竟不是特定为完成某功能而定制的，所以就算是按需加载，仍然可能会存在无用代码。这个是无法解决的，我们得认识到，只可能尽量减少冗余，不可能根除冗余。

很多同行容易犯一个错误，就是拿到一个任务后就马上开始写代码，其实这并不是一个好习惯。

对于简单的独立页面而言，这么做还不会有太大麻烦。但是，对于一个中大型的网站而言，如果在还没有一个考虑成熟的前端架框前就开始动手写代码是会带来非常多问题的，比如代码冗余、多人合作容易冲突、代码组织没有规律等。

犯这种错误主要因为两个方面的原因：一方面可能是工程师本身经验不足；另一方面可能是客户或Boss给的压力很大，拼命赶工期。如果是后者，我们一定要顶住压力，客户和Boss往往很可能并不了解技术，它们可能更希望尽快看到工作成果。如果在没有一个成熟的框架前就开始写代码，很可能会出现先快后慢的局面，越到后期开发速度越慢，反复修改bug、打补丁，系统的开发和维护成本越来越大。如果一开始不急于马上进行开发，而是先根据用户需求进行分析，先考虑好框架，会让整个开发过程更有规划、更顺畅，是一个先慢后快的过程。

前期的构思非常重要。具体来说，构思的内容主要包括规范的制定、公共组件的设计和复杂功能的技术方案等。一般来说，前期构思占整个项目30%～60%的时间都算是正常的。要知道，磨刀不误砍柴工！

规范对于团队合作来说是最重要的。它能有效指导团队成员按照一个统一的标准进行开发，尽量让开发过程平滑，减少不必要的冲突，提高开发率并保证软件的质量。

规范会随制定者的经验和风格而不同，没有一个统一标准和准则，主观性非常强。因为规范的好坏会直接影响整个开发过程，所以它通常是由团队中经验最丰富的人来制定的。正是由于规范的主观性强，所以不同的公司有不同的规范。

笔者抛砖引玉，奉上自己制订的一份规范，供大家参考详见附录。

依笔者的经验来看，团队合作的最大难度其实并不是技术，而是人。

只要有一定经验，构思良好，有完善的规范，尽管最终代码可能有好有坏，但团队合作在技术上并不太可能出现大的困难。团队合作最大的问题还是来自于团队中成员之间的交流。不同的工程师的说话方式、工作习惯、性格特点也可能各异，工作中出现观点不同的情形在所难免。不同工程师在处理这样的问题时表现出的态度也不一样，有些比较温柔，有些则可能稍显强硬，有些可能比较容易接受他人观点，有些则可能固执己见。如果处理不好，可能会产生火药味，让大家带着情绪工作，影响开发进度。

工程师往往都更专注于技术，不太善于处理人际关系。比起复杂的人，大多数工程师往往更喜欢与非黑即白，非0即1，非true即false的代码相处。学会与人相处也是工程师们必修的一门课，它的重要性甚至超过了技术本身。

切记，自己能独立决策的问题都是小问题，要与人合作商讨的问题才可能会是最大的问题，要学会与人相处。