Web 标准是一套理论性的指导思想，它的最终目的是让代码更易于维护，标准本身是手段，而不是目的。在应用
Web 标准的实践中，有时候不遵循标准反而能带来更好的可维护性，如果你确信你的方案利大于弊，那么就去做
吧，尽信标准不如无标准，过于教条主义是一件很愚蠢的事情。
如果你对以上信息有意见，请用脚投票。
前端开发工程师是一个新兴的职业，关于它的职能定位，包括很多同行在内，都比较模糊，下面是盛大公司的一
则招聘中对前端开发工程师的要求：
1.绝对熟练 div+css 制作方式，对网页标准有独特的见解；
2.精通 XHTML\CSS\JavaScript，熟练使用 javascript 前端脚本，要有常用效果和功能的积累，会用常见的

javascript 类库，如 jQuery 或 Mootols 等，理解异步请求的远离，可以配合程序员开发一些简单的 Ajax 应
用。
3.至少了解一门后台语言，例如 PHP 或 ASP.NET
4.熟练使用网页设计相关的软件

5.两年以上团队协作开发经验，有责任心、爱钻研、爱思考
6.具有本科及以上学历。

大家可能注意到，在盛大的招聘信息中，

Flash 并没有被提及！这是因为，随着 Web 标准的推广，前端开发工程

——

师的本职工作已经重点落到了网页的制作商，网页三要素

结构、样式、行为，也就是

HTML、CSS 和

JavaScript 才是前端开发工程师的核心工作，而 Flash 作为富媒体应用，从前端开发中被分离出来，由于专门
的

Flash 开发工程师负责。

前端开发位于网站开发的中游，上游有交互设计师和视觉设计师，下游有服务器端工程师，前端开发工程师需要
与他们沟通，所以需关注的知识面非常广。

“ ”

将前端开发和服务器端开发做一个比较，前端开发没有服务器端开发深，服务器端开发没有前端开发广。经
常听过做前端的朋友抱怨需要学的东西太多，东学一点西学一点，什么都会，但也什么都不精。很直接的结果就

“

是沦为打杂的程序员，对能力没自信，在团队里说话也不够分量。所以很多前端得出了一个结论：通十行不如精

”

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

“

一个保证代码可读性良好的绝佳武器就是注释，关于注释在美国有一种说话：一个好的代码，注释要站

1/3 的篇

”

幅。虽然有些夸张了点，不过他表明了注释的重要性。
公共组件和私有组件的维护
团队合作很容易产生的问题之一就是冗余。如果没有实现做好规划，很容易出现这样一种情况：工程师甲在页面

上为了实现某种效果写了一段代码，工程师乙在页面

B 上遇到同样的问题时又重写了一遍。如果系统升级，这个

效果需要改变，那么工程师甲和工程师乙都需要更改这部分代码，明显是一种资源浪费。
避免出现这种冗余的最好办法就是根据代码的重用度，把它们分成公公组件和私有组件两类。设计公公组件时需
要考虑让接口保持弹性，并且高度模块化，这是很考研能力和经验的工作。因为公公组件在设计之初就是考虑到
要被多人多处重复使用的，如果公公组件一旦被修改会造成很大影响！所以我们需要对公公组件的稳定性保持高
度晶体，不允许轻易做修改。公公组件需要由专人来维护。负责维护公公组件的工程师需要将公公组件做好注释，
必要时甚至需要提供范例的

API 文档和演示 Demo。其他工程师在工作中如果需要高度重用的模块，而公公组件中

尚未提供，可以向维护公公组件的工程师提交需求，让他来添加相应的公公组件。私有组件因为不考虑其他人重
用的问题，所以对于修改操作会自由得多。但不要忘记，虽然你的私有组件不会被他人重用，但仍然可能会被他
人维护，所以必要的注释还是需要的。

——

有了公公组件和私有组件的区分，可以有效避免代码的重复。但优惠带来新的问题

如何组织公公组件。

一般来说，合理的前端架构中

CSS 和 JavaScript 都会提取公公组件，如何组织公公组件是需要权衡的。如果没

有将公公组件再入到系统中，那么组建是没法被使用的。一个最方便的做法就是将公公组件全部打包好，然后一
次性全部再入，这样可以保证所有的组件都是可用的。这种做法的好处是夹在方便，但加载的代码量可能过大，
而很多代码事实上很可能是没有被用到的。另一种做法是将代码精确划分成一小块一小块，然后按需加载相应的
模块。这种做法的好处是夹在灵活，保证代码的夹在两小，但坏处是使用起来比较麻烦。
我们在组织公共组建时，组织的粒度越大，文件越集中，加载和管理越方便，但无用代码越多；组织的粒度越小，
文件越分散，加载和管理越麻烦，但吴用代码越少。我们要加载方便就要适当舍弃精简性，要保证精简性就要适
当放弃加载的方便性。我们需要认识到一点：完美的解决方案是不存在的，我们只能在冗余和精简中尽量找到最
佳的平衡点。
很多同行容易犯一个错误，就是拿到一个任务后马上开始写代码，其实这并不是一个好习惯。对于简单的独立页
面而言，这么做还不会有台大麻烦。但是，对于一个中大型的网站而言，如果在还没有一个考虑成熟的前端框架
前就开始动手写代码是会带来非常多问题的，比如代码冗余、多人合作容易冲突、代码组织没有规律等。
犯这种错误主要因为两个方面的原因：一方面可能是经验不足；另一方面可能是客户或

Boss 给的压力很大，拼命

赶工期。如果是后者，我们一定要顶住压力，客户和

Boss 往往很可能并不了解技术，他们可能更希望尽快看到工

作成果。如果一开始不急于马上进行开发，而是先根据用户需求进行分析，先考虑好框架，会让整个开发过程更
有规划、更顺畅，是一个先慢后快的过程。
前期的构思非常重要。具体来说，构思的内容主要包括规范的制定、公公组件的设计和复杂功能的技术方案等。
一般来说，前期构思占整个项目

30%~60%时间都算是正常的。要知道，磨刀不误砍柴工！