（已有35条评价）
基本信息
- 原书名：Maintainable JavaScript
- 原出版社： O'Reilly Media
- 作者： (美)Nicholas C. Zakas
- 译者： 李晶 郭凯 张散集
- 出版社：人民邮电出版社
- ISBN：9787115310088
- 上架时间：2013-3-25
- 出版日期：2013 年4月
- 开本：16开
- 页码：226
- 版次：1-1
- 所属分类：计算机 > 软件与程序设计 > 网络编程 > javascript
编辑推荐
构建编码风格手册，帮助开发团队从“游击队”走向“正规军”
相关推荐:
《JavaScript语言精粹(修订版)》
《JavaScript权威指南(第6版)》
《JavaScript高级程序设计(第3版)》
《JavaScript核心概念及实践》
《JavaScript异步编程：设计快速响应的网络应用》
内容简介
书籍
计算机书籍
任何语言都需要强调编码风格的一致性。只要是团队开发，每个人都以相同方式编写代码就是至关重要的。这样大家才能方便地互相看懂和维护对方的代码。
《编写可维护的JavaScript》向开发人员阐述了如何在团队开发中编写具备高可维护性的JavaScript代码，书中详细说明了作为团队一分子，应该怎么写JavaScript。本书内容涵盖了编码风格、编程技巧、自动化、测试等几方面，既包括具体风格和原则的介绍，也包括示例和技巧说明，最后还介绍了如何通过自动化的工具和方法来实现一致的编程风格。
《编写可维护的JavaScript》作者Nicholas C. Zakas是顶级的Web技术专家，也是《JavaScript高级程序设计》一书的作者。他曾是Yahoo！的首席前端开发工程师，在完成了从一名“独行侠”到“团队精英”的蜕变后，他站在前端工程师的角度提炼出众多的最佳编程实践，其中包括很多业内权威所推崇的最佳法则，而这些宝贵经验正是本书的核心内容。
《编写可维护的JavaScript》适合前端开发工程师、JavaScript程序员和学习JavaScript编程的读者阅读，也适合开发团队负责人、项目负责人阅读。运用本书中讲述的技巧和技术，可以使JavaScript团队编程从侠义的个人偏好的阴霾走出来，走向真正的高可维护性、高效能和高水准。
计算机书籍
任何语言都需要强调编码风格的一致性。只要是团队开发，每个人都以相同方式编写代码就是至关重要的。这样大家才能方便地互相看懂和维护对方的代码。
《编写可维护的JavaScript》向开发人员阐述了如何在团队开发中编写具备高可维护性的JavaScript代码，书中详细说明了作为团队一分子，应该怎么写JavaScript。本书内容涵盖了编码风格、编程技巧、自动化、测试等几方面，既包括具体风格和原则的介绍，也包括示例和技巧说明，最后还介绍了如何通过自动化的工具和方法来实现一致的编程风格。
《编写可维护的JavaScript》作者Nicholas C. Zakas是顶级的Web技术专家，也是《JavaScript高级程序设计》一书的作者。他曾是Yahoo！的首席前端开发工程师，在完成了从一名“独行侠”到“团队精英”的蜕变后，他站在前端工程师的角度提炼出众多的最佳编程实践，其中包括很多业内权威所推崇的最佳法则，而这些宝贵经验正是本书的核心内容。
《编写可维护的JavaScript》适合前端开发工程师、JavaScript程序员和学习JavaScript编程的读者阅读，也适合开发团队负责人、项目负责人阅读。运用本书中讲述的技巧和技术，可以使JavaScript团队编程从侠义的个人偏好的阴霾走出来，走向真正的高可维护性、高效能和高水准。
作译者
Nicholas C. Zakas是一名前端开发顾问、作者、演讲家。他在Yahoo! 供职超过5年时间。在这期间，他曾是Yahoo！首页首席前端工程师和YUI代码贡献者。他著有《JavaScript高级程序设计》、《Ajax高级程序设计》和《高性能JavaScript》。他的博客地址是：http://www.nczonline.net/。他的Twitter是：@slicknet。
李晶，花名拔赤，淘宝前端工程师，具有多年前端开发经验，在团队协作、组件开发、移动Web App等方面有深入研究，曾经参与淘宝首页、KISSY等项目开发。他翻译过《JavaScript Web富应用开发》、《JavaScript权威指南（第六版）》、《What is Node?》等书籍，热爱分享，喜欢折腾。微博http://weibo.com/jayli。
郭凯，花名流火，淘宝前端工程师，喜欢登山，也喜欢夜深人静时一人静静地写代码，折腾过许多小站均未能持久，有In、Juicer等开源项目。钟爱JavaScript，也喜欢Python，自嘲所学杂而不精。博客http://benben.cc。
张散集，花名一舟，淘宝前端工程师。他主要从事技术管理，负责淘宝网（北京）的新业务技术和前端团队，热爱前端新技术的推广与应用。翻译作品有《JavaScript Web富应用开发》和《JavaScript权威指南（第六版）》。
李晶，花名拔赤，淘宝前端工程师，具有多年前端开发经验，在团队协作、组件开发、移动Web App等方面有深入研究，曾经参与淘宝首页、KISSY等项目开发。他翻译过《JavaScript Web富应用开发》、《JavaScript权威指南（第六版）》、《What is Node?》等书籍，热爱分享，喜欢折腾。微博http://weibo.com/jayli。
郭凯，花名流火，淘宝前端工程师，喜欢登山，也喜欢夜深人静时一人静静地写代码，折腾过许多小站均未能持久，有In、Juicer等开源项目。钟爱JavaScript，也喜欢Python，自嘲所学杂而不精。博客http://benben.cc。
张散集，花名一舟，淘宝前端工程师。他主要从事技术管理，负责淘宝网（北京）的新业务技术和前端团队，热爱前端新技术的推广与应用。翻译作品有《JavaScript Web富应用开发》和《JavaScript权威指南（第六版）》。
目录
《编写可维护的JavaScript》
第一部分 编程风格 1
第1章 基本的格式化 4
1.1 缩进层级 4
1.2 语句结尾 7
1.3 行的长度 8
1.4 换行 9
1.5 空行 10
1.6 命名 11
1.6.1 变量和函数 12
1.6.2 常量 13
1.6.3 构造函数 14
1.7 直接量 15
1.7.1 字符串 15
1.7.2 数字 16
1.7.3 null 17
1.7.4 undefined 18
1.7.5 对象直接量 19
1.7.6 数组直接量 20
第2章 注释 21
第一部分 编程风格 1
第1章 基本的格式化 4
1.1 缩进层级 4
1.2 语句结尾 7
1.3 行的长度 8
1.4 换行 9
1.5 空行 10
1.6 命名 11
1.6.1 变量和函数 12
1.6.2 常量 13
1.6.3 构造函数 14
1.7 直接量 15
1.7.1 字符串 15
1.7.2 数字 16
1.7.3 null 17
1.7.4 undefined 18
1.7.5 对象直接量 19
1.7.6 数组直接量 20
第2章 注释 21
译者序
在我的编程生涯中，曾遇到过各种各样的开发者，他们的编程风格天马行空，有时甚至让人哭笑不得。有一种风格被称为“霰弹枪编程”，例如某个方法调用出错了，我尝试将参数0改为'0'、NaN甚至false，直到试出能“正确”运行的参数为止。当你和这种人组成团队一起编程时，你会发现你的智商变得很低。
比“霰弹枪编程”更温柔一点的编程方式是“撞大运编程”，就是我根本看不懂程序到底在干嘛，但确实能正常运行，这往往是因为这些程序中有很多错误成对出现，于是就负负得正，看起来就正确了，这种程序实在是“动弹不得”，只能重构。当你和这种人组成团队时，上帝都会同情你。
当然，当渐渐意识到这类随意编程风格带来的危害时，很多人开始思考什么才是“好”的编程风格。不少人开始向高手学习，尽管有时并不知道高手为什么要把代码写成这个样子。于是越来越多的hack代码出现了，那些看起来晦涩难懂、短小精悍却又暂时行之有效的代码片段越来越流行，尤其是在处理浏览器兼容性问题时，这种情况更甚。有些人会在这些hack代码片段旁边打上记号，以便以后有问题时能留意到此。这时，问题又出现了，不同人做记号的方法又不一样，我的天哪！
如果你自诩为一名有能力有良知的程序员，遇到这种“烂”代码时往往将之重构，为了修改几个拼写错误的bug，而修改10个类，并且重构与这10个类有关联的另外20个类，甚至修改了打包脚本以及部署配置文件。这就是一种有着代码洁癖的人很“青睐”的编程风格—“屠宰式编程”。
霰弹枪式、撞大运式、不求甚解式、屠宰式……
编程是一项复杂的工程，却又如此充满喜感，让人又爱又恨。但有一点确定无疑，即这些风格因为缺少基本的约束，会导致团队协作效率低下，甚至影响产品的存亡。而对于Web开发领域最为流行却有着先天设计缺陷的语言JavaScript来说，情况更加糟糕。一直以来都缺少宏观的设计模式和微观的编程风格的指导，从而导致JavaScript编程始终没有权威和统一的指导思想和方法论。因此，大部分Web前端团队依然将很大精力放在解决注入代码冲突、命名规范性、代码复用模式等团队编程最基本的问题上。迟迟走不上创新、高效的快车道。
我们很欣喜地看到，在设计模式领域，《JavaScript设计模式》（JavaScript Design Patterns）和《JavaScript编程模式》（JavaScript Patterns）两本书填补了这方面的空白，而在编程风格领域，这本《编写可维护的JavaScript》（Maintainable JavaScript）真可谓姗姗来迟。
本书正是向开发人员阐述如何在团队开发中编写高可维护的JavaScript代码，涵盖了编码风格、编程技巧、自动化、测试等几方面，不过，同样的原则也适用于其他任何语言。本书作者是大名鼎鼎的Nicholas C. Zakas。他曾是Yahoo!的首席前端开发工程师，在完成了从一名独行侠到团队精英的蜕变后，他站在前端工程师的角度为我们提炼出许多的最佳编程实践，其中包括很多来自工业生产的最佳法则。应用这些技巧和技术，可以使你的团队编程从侠义的个人偏好的阴霾走出来，走向真正的高效和高水准。
本书由淘宝北京前端团队翻译，在翻译过程中，我们始终保持一种学习的心态，因为正像前面提到的，作者给出的很多经验正是我们手头工作中不在意却又至关重要的，这种学习心态也让我们在这次翻译过程收获颇丰。我们尽最大的努力，力求翻译后的表述在还原作者原意的同时又不失中文的流畅。但难免由于译者水平有限而有所纰漏，还请各位高手多多批评指正。
最后，我要感谢人民邮电出版社信息技术分社的陈冀康老师的信任和鼓励，宁愿让我们多花些时间来保证质量，同时感谢我的同事魏凡哲（陶清）、贺亮（完真）、杨翰文（地极）、王保平（玉伯）参与本书的试读和审校。如果要提交本书的勘误和建议，请在本书的介绍页面留言（http://jayli.github.com/maintainable.javascript）。
李晶（拔赤），郭凯（流火），张散集（一舟）
2013年1月
比“霰弹枪编程”更温柔一点的编程方式是“撞大运编程”，就是我根本看不懂程序到底在干嘛，但确实能正常运行，这往往是因为这些程序中有很多错误成对出现，于是就负负得正，看起来就正确了，这种程序实在是“动弹不得”，只能重构。当你和这种人组成团队时，上帝都会同情你。
当然，当渐渐意识到这类随意编程风格带来的危害时，很多人开始思考什么才是“好”的编程风格。不少人开始向高手学习，尽管有时并不知道高手为什么要把代码写成这个样子。于是越来越多的hack代码出现了，那些看起来晦涩难懂、短小精悍却又暂时行之有效的代码片段越来越流行，尤其是在处理浏览器兼容性问题时，这种情况更甚。有些人会在这些hack代码片段旁边打上记号，以便以后有问题时能留意到此。这时，问题又出现了，不同人做记号的方法又不一样，我的天哪！
如果你自诩为一名有能力有良知的程序员，遇到这种“烂”代码时往往将之重构，为了修改几个拼写错误的bug，而修改10个类，并且重构与这10个类有关联的另外20个类，甚至修改了打包脚本以及部署配置文件。这就是一种有着代码洁癖的人很“青睐”的编程风格—“屠宰式编程”。
霰弹枪式、撞大运式、不求甚解式、屠宰式……
编程是一项复杂的工程，却又如此充满喜感，让人又爱又恨。但有一点确定无疑，即这些风格因为缺少基本的约束，会导致团队协作效率低下，甚至影响产品的存亡。而对于Web开发领域最为流行却有着先天设计缺陷的语言JavaScript来说，情况更加糟糕。一直以来都缺少宏观的设计模式和微观的编程风格的指导，从而导致JavaScript编程始终没有权威和统一的指导思想和方法论。因此，大部分Web前端团队依然将很大精力放在解决注入代码冲突、命名规范性、代码复用模式等团队编程最基本的问题上。迟迟走不上创新、高效的快车道。
我们很欣喜地看到，在设计模式领域，《JavaScript设计模式》（JavaScript Design Patterns）和《JavaScript编程模式》（JavaScript Patterns）两本书填补了这方面的空白，而在编程风格领域，这本《编写可维护的JavaScript》（Maintainable JavaScript）真可谓姗姗来迟。
本书正是向开发人员阐述如何在团队开发中编写高可维护的JavaScript代码，涵盖了编码风格、编程技巧、自动化、测试等几方面，不过，同样的原则也适用于其他任何语言。本书作者是大名鼎鼎的Nicholas C. Zakas。他曾是Yahoo!的首席前端开发工程师，在完成了从一名独行侠到团队精英的蜕变后，他站在前端工程师的角度为我们提炼出许多的最佳编程实践，其中包括很多来自工业生产的最佳法则。应用这些技巧和技术，可以使你的团队编程从侠义的个人偏好的阴霾走出来，走向真正的高效和高水准。
本书由淘宝北京前端团队翻译，在翻译过程中，我们始终保持一种学习的心态，因为正像前面提到的，作者给出的很多经验正是我们手头工作中不在意却又至关重要的，这种学习心态也让我们在这次翻译过程收获颇丰。我们尽最大的努力，力求翻译后的表述在还原作者原意的同时又不失中文的流畅。但难免由于译者水平有限而有所纰漏，还请各位高手多多批评指正。
最后，我要感谢人民邮电出版社信息技术分社的陈冀康老师的信任和鼓励，宁愿让我们多花些时间来保证质量，同时感谢我的同事魏凡哲（陶清）、贺亮（完真）、杨翰文（地极）、王保平（玉伯）参与本书的试读和审校。如果要提交本书的勘误和建议，请在本书的介绍页面留言（http://jayli.github.com/maintainable.javascript）。
李晶（拔赤），郭凯（流火），张散集（一舟）
2013年1月
前言
本书约定
这个图标表示一种提示、建议或一般性的提醒。
这个图标表示一种警告。
使用示例代码
本书是为了帮助你完成你的工作。通常来讲，你可以任意使用本书中的程序和文档。你不需要在这之前联系我们获得使用许可，但若复制程序的关键部分除外。比如，你的程序使用了本书中的多段代码，这不需要获取我们的许可。出售或者散布O'Reilly的书籍的示例代码光盘则需要首先获得授权。通过引用本书的内容或者代码来回答问题不需要预先获得许可，但将本书的示例代码的关键部分合并入你的产品或者文档则需要获得我们的许可。
我们不要求你一定注明本书的出处。一个完整的出处说明应当包括标题、作者、出版社和ISBN。比如：Maintainable JavaScript，作者Nicholas Zakas（O'Reilly）。Copyright 2012 Nicholas Zakas，978-1-449-32768-2。
如果你发现有人在我们的授权范围之外使用了示例代码，请联系我们permissions@
oreilly.com。
如何联系我们
对于本书的评论或问题请联系出版商：
美国：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
申请会员或订阅图书目录，请发送邮件至：
info@oreilly.com
技术问题或评论本书，请发送邮件至：
这个图标表示一种提示、建议或一般性的提醒。
这个图标表示一种警告。
使用示例代码
本书是为了帮助你完成你的工作。通常来讲，你可以任意使用本书中的程序和文档。你不需要在这之前联系我们获得使用许可，但若复制程序的关键部分除外。比如，你的程序使用了本书中的多段代码，这不需要获取我们的许可。出售或者散布O'Reilly的书籍的示例代码光盘则需要首先获得授权。通过引用本书的内容或者代码来回答问题不需要预先获得许可，但将本书的示例代码的关键部分合并入你的产品或者文档则需要获得我们的许可。
我们不要求你一定注明本书的出处。一个完整的出处说明应当包括标题、作者、出版社和ISBN。比如：Maintainable JavaScript，作者Nicholas Zakas（O'Reilly）。Copyright 2012 Nicholas Zakas，978-1-449-32768-2。
如果你发现有人在我们的授权范围之外使用了示例代码，请联系我们permissions@
oreilly.com。
如何联系我们
对于本书的评论或问题请联系出版商：
美国：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
申请会员或订阅图书目录，请发送邮件至：
info@oreilly.com
技术问题或评论本书，请发送邮件至：
序言
由于前端工程师的成长道路自成轨迹，这让（Web前端技术）这个专业看起来是如此的与众不同，甚至诸如Yahoo！这种大公司里的很多前端工程师也多是靠自身野蛮生长，我行我素地写着各种hack！ 。或许你曾经也是一名小公司里的“页面仔”（the web guy），那时的你几乎什么都干。当大公司开始利用这些之前未被发掘的资源时 ，团队协作的环境短时间内吸纳了很多“hacker” ，这时这些hacker碰到了各种条条框框。单兵作战再也没了优势，所有那些自学成才和以自我为中心的人都不得不开始思考如何才能在团队环境中生存下来。
我是在20世纪90年代末开始学习JavaScript的：靠的是自学。因为当时的JavaScript还很新潮，学习资料很少。和其他很多开发者一样，我通过不断钻研IE和Netscape Navigator来自学。我做各种尝试、梳理我所掌握的知识，我一遍遍反复试验，直到搞清楚其工作原理。幸运的是，这份好奇和勤勉为我带来了第一份工作。
在我职业生涯的第一个五年中，我是一个“脚本仔”。在我最早呆过的两家公司里，没有人比我更了解JavaScript和Web开发。所有问题，不管是非常简单的还是非常复杂的，我都能搞定。我刚刚从学校毕业，是一名初出茅庐的小伙子，却有着一种危机感。因为我找不出能和我产生思想碰撞的人，并且在我遇到问题时也没有人能为我解难。我力争做到最好，因为我知道我是唯一能做到这样的人。
在这五年之中，我不断磨炼我的技能。我让我的做事方式和工作流程更为合理。我不用担心其他人去研究我的代码，因为别人都没有能力给我做代码评审（review）或为我的代码提交bug修复。我是一个纯粹意义上的hacker：我行我素地写着代码，而且不用担心它会被修改。
在我职业生涯的第六年，我换了工作，加入了一个团队，在这个团队中，每个人都会为项目的各个方面贡献代码。我的主要精力不再是JavaScript和Web开发，而是大部分时间在写后端代码和SQL。同时，传统的后端工程师却开始被迫写前端（页面）代码。这种体验真正让我大开眼界：我之前写代码的方式和团队其他人实在是格格不入，这是一个大问题。
我很快意识到要想更高效地参与团队开发，我写代码的方式必须和团队保持一致。后台代码和SQL对我来说有点陌生，因此我采纳了身边一些有头脑的人写代码的模式。与此同时，我开始与其他工程师讨论我们应当采纳何种HTML、CSS和JavaScript的编程模式。我甚至在编译阶段加入了JavaScirpt语法检查来强制推行标准—这也是我第一次在公司做 Web 代码的检查。不久以后，这个团队就像上了润滑油的机器一样高效。
我在2006年加入了Yahoo！。我一到Yahoo！就发现几乎所有工作都和相互协作有关。整个团队就像把不同的动物纠集在一起。我所加入的第一个团队是My Yahoo！团队，这个团队非常庞大，比我之前工作过的任何团队都要大。团队里也有很多成型的编程指南，我有很多需要学习的东西。新技术、新流程以及新工具一股脑地展现在我面前。我花了大量的时间来学习这些新环境，吸收新知识，而这些知识是我从大学里接触不到的。在这里我完全沉浸在知识的海洋里，感觉自己像被重塑了一般。
几个月后，我开始遇到一些问题。我所习惯的开发流程并不是总能好好工作。有不少人以不同的方式来做事，这导致了很多bug。我的主管发现了这一苗头，一天他把我叫到一边，告诉我他希望我来负责梳理我们的开发。现在回想起他的话依然是那么鼓舞人心：“你写的代码都可以运行得很好，很少出bug。我希望其他人都像你一样写代码。”就这样，我打算着手为My Yahoo！前端开发团队注入一些结构和规范。
我为My Yahoo！团队做的工作非常成功，最终我被遴选为2008年Yahoo！新版首页的首席前端工程师。这次委任让我有机会将代码组织和测试高质量代码的技巧，应用于一个拥有20名前端工程师的团队，让这20名工程师只开发一种（风格的）代码。通过几个月的学习和调整，这个团队的生产效率和产品质量达到了一个很高的水平，让很多人叹为观止。不管是谁写的代码，它们都看起来像出自一个人之手，此外，多数工程师都可以快速地接手别人的工作来修复bug或开发新功能。在此期间，作为一个工程师团队所产出的业绩，在过去的几年里一直是我职业生涯的最大亮点。
我在Yahoo！的这段时间都是在参与大型的团队开发，我将在此期间积累的所有经验和方法整理出来成书于此。所讨论的主题也体现了我的这种蜕变，我从一名我行我素的独行侠，蜕变为一名软件工程师，一名团队协作者，我放弃了我身上固有的侠气和个性，来让整个团队以更高的水准运作。这正是这本书的内容：如何站在团队的角度去写JavaScript代码。
开发者最不容易理解的事情是，我们为何需要花这么多时间来“维护”代码。很少有人会打开一个文本编辑器从头开始写代码。大多数时间里，你面对的都是已经写好的代码。以一种可维护的方式来写代码，可以让你和协作者很容易就知道上段代码写到什么地方什么程度。正如我在Yahoo！时常说的：“当你开始工作时，你不是在给你自己写代码，而是为后来人写代码。”
本书收集了很多关于JavaScript编程规范的讨论。“Java语言编码规范”（Code Conventions for the Java Programming Language） 是当前最流行的关于编码规范的文档之一，它指出编码规范如此重要的几个原因。
软件生命周期中80%的成本消耗在了维护上。
几乎所有的软件维护者都不是它的最初作者。
编码规范提高了软件的可读性，它让工程师能够快速且充分地理解新的代码。
如果你将源码作为产品来发布，你需要确保它是可完整打包的，且像你创建的其他产品一样整洁。
这些原因在今天看来依然适用。本书所讨论的编程规范也是着眼于帮助你和你的团队写出高效的JavaScript代码。
因为你正在阅读这本书，你需要对本书提到的一些建议保持开放的心态。要知道这里说的很多技术，真正的目标是解决多人开发的环境中很多工程师如何书写统一风格的代码的问题。作为团队的一员，意味着做出这种决策不仅对个人有好处，对于团队也同样有好处。对于个人来说，需要在一定程度上牺牲个人偏好、个人观点甚至个人英雄主义。你所收获的是一个能做大事的高效的团队，我希望这本书可以帮助你做到这一点。
我是在20世纪90年代末开始学习JavaScript的：靠的是自学。因为当时的JavaScript还很新潮，学习资料很少。和其他很多开发者一样，我通过不断钻研IE和Netscape Navigator来自学。我做各种尝试、梳理我所掌握的知识，我一遍遍反复试验，直到搞清楚其工作原理。幸运的是，这份好奇和勤勉为我带来了第一份工作。
在我职业生涯的第一个五年中，我是一个“脚本仔”。在我最早呆过的两家公司里，没有人比我更了解JavaScript和Web开发。所有问题，不管是非常简单的还是非常复杂的，我都能搞定。我刚刚从学校毕业，是一名初出茅庐的小伙子，却有着一种危机感。因为我找不出能和我产生思想碰撞的人，并且在我遇到问题时也没有人能为我解难。我力争做到最好，因为我知道我是唯一能做到这样的人。
在这五年之中，我不断磨炼我的技能。我让我的做事方式和工作流程更为合理。我不用担心其他人去研究我的代码，因为别人都没有能力给我做代码评审（review）或为我的代码提交bug修复。我是一个纯粹意义上的hacker：我行我素地写着代码，而且不用担心它会被修改。
在我职业生涯的第六年，我换了工作，加入了一个团队，在这个团队中，每个人都会为项目的各个方面贡献代码。我的主要精力不再是JavaScript和Web开发，而是大部分时间在写后端代码和SQL。同时，传统的后端工程师却开始被迫写前端（页面）代码。这种体验真正让我大开眼界：我之前写代码的方式和团队其他人实在是格格不入，这是一个大问题。
我很快意识到要想更高效地参与团队开发，我写代码的方式必须和团队保持一致。后台代码和SQL对我来说有点陌生，因此我采纳了身边一些有头脑的人写代码的模式。与此同时，我开始与其他工程师讨论我们应当采纳何种HTML、CSS和JavaScript的编程模式。我甚至在编译阶段加入了JavaScirpt语法检查来强制推行标准—这也是我第一次在公司做 Web 代码的检查。不久以后，这个团队就像上了润滑油的机器一样高效。
我在2006年加入了Yahoo！。我一到Yahoo！就发现几乎所有工作都和相互协作有关。整个团队就像把不同的动物纠集在一起。我所加入的第一个团队是My Yahoo！团队，这个团队非常庞大，比我之前工作过的任何团队都要大。团队里也有很多成型的编程指南，我有很多需要学习的东西。新技术、新流程以及新工具一股脑地展现在我面前。我花了大量的时间来学习这些新环境，吸收新知识，而这些知识是我从大学里接触不到的。在这里我完全沉浸在知识的海洋里，感觉自己像被重塑了一般。
几个月后，我开始遇到一些问题。我所习惯的开发流程并不是总能好好工作。有不少人以不同的方式来做事，这导致了很多bug。我的主管发现了这一苗头，一天他把我叫到一边，告诉我他希望我来负责梳理我们的开发。现在回想起他的话依然是那么鼓舞人心：“你写的代码都可以运行得很好，很少出bug。我希望其他人都像你一样写代码。”就这样，我打算着手为My Yahoo！前端开发团队注入一些结构和规范。
我为My Yahoo！团队做的工作非常成功，最终我被遴选为2008年Yahoo！新版首页的首席前端工程师。这次委任让我有机会将代码组织和测试高质量代码的技巧，应用于一个拥有20名前端工程师的团队，让这20名工程师只开发一种（风格的）代码。通过几个月的学习和调整，这个团队的生产效率和产品质量达到了一个很高的水平，让很多人叹为观止。不管是谁写的代码，它们都看起来像出自一个人之手，此外，多数工程师都可以快速地接手别人的工作来修复bug或开发新功能。在此期间，作为一个工程师团队所产出的业绩，在过去的几年里一直是我职业生涯的最大亮点。
我在Yahoo！的这段时间都是在参与大型的团队开发，我将在此期间积累的所有经验和方法整理出来成书于此。所讨论的主题也体现了我的这种蜕变，我从一名我行我素的独行侠，蜕变为一名软件工程师，一名团队协作者，我放弃了我身上固有的侠气和个性，来让整个团队以更高的水准运作。这正是这本书的内容：如何站在团队的角度去写JavaScript代码。
开发者最不容易理解的事情是，我们为何需要花这么多时间来“维护”代码。很少有人会打开一个文本编辑器从头开始写代码。大多数时间里，你面对的都是已经写好的代码。以一种可维护的方式来写代码，可以让你和协作者很容易就知道上段代码写到什么地方什么程度。正如我在Yahoo！时常说的：“当你开始工作时，你不是在给你自己写代码，而是为后来人写代码。”
本书收集了很多关于JavaScript编程规范的讨论。“Java语言编码规范”（Code Conventions for the Java Programming Language） 是当前最流行的关于编码规范的文档之一，它指出编码规范如此重要的几个原因。
软件生命周期中80%的成本消耗在了维护上。
几乎所有的软件维护者都不是它的最初作者。
编码规范提高了软件的可读性，它让工程师能够快速且充分地理解新的代码。
如果你将源码作为产品来发布，你需要确保它是可完整打包的，且像你创建的其他产品一样整洁。
这些原因在今天看来依然适用。本书所讨论的编程规范也是着眼于帮助你和你的团队写出高效的JavaScript代码。
因为你正在阅读这本书，你需要对本书提到的一些建议保持开放的心态。要知道这里说的很多技术，真正的目标是解决多人开发的环境中很多工程师如何书写统一风格的代码的问题。作为团队的一员，意味着做出这种决策不仅对个人有好处，对于团队也同样有好处。对于个人来说，需要在一定程度上牺牲个人偏好、个人观点甚至个人英雄主义。你所收获的是一个能做大事的高效的团队，我希望这本书可以帮助你做到这一点。
媒体评论
“本书是一本教你写出具有前瞻性的JavaScirpt代码的完全手册，在团队作战中特别有用。”
——Ryan Grove，Yahoo! YUI工程师
“作者将他十多年工作经验的精华部分浓缩至这本通俗易读的书中。我建议每个开发工程师和在校学生尽早阅读本书。不管你有多少经验，本书中的每一页内容都会让你变得更加优秀且倍受大家欢迎。”
——Lea Verou，Web设计师兼Web开发人员
“ 这是一本前端工程师的指南，指明了在编码过程需要注意的方方面面。提高可维护性是一个非常大的话题，而这本书，是一个非常不错的起点。”
——王保平（玉伯），支付宝Web前端工程师
——Ryan Grove，Yahoo! YUI工程师
“作者将他十多年工作经验的精华部分浓缩至这本通俗易读的书中。我建议每个开发工程师和在校学生尽早阅读本书。不管你有多少经验，本书中的每一页内容都会让你变得更加优秀且倍受大家欢迎。”
——Lea Verou，Web设计师兼Web开发人员
“ 这是一本前端工程师的指南，指明了在编码过程需要注意的方方面面。提高可维护性是一个非常大的话题，而这本书，是一个非常不错的起点。”
——王保平（玉伯），支付宝Web前端工程师
书摘
插图：
方法封装了从DOM中删除一个元素的操作，屏蔽了开发者要访问该元素父节点的需求。
从JavaScript的可维护性而言，门面是非常合适的方式，自己可以完全控制这些接口。你可以允许访问任何底层对象的属性或方法，反之亦然，也就是有效地过滤对该对象的访问。你也可以对已有的方法进行改造，使其更加简单易用（上段示例代码就是一个案例）。底层的对象无论如何改变，只要修改门面，应用程序就能继续正常工作。
门面实现一个特定接口，让一个对象看上去像另一个对象，就称作一个适配器。门面和适配器唯一的不同是前者创建新接口，后者实现已存在的接口。
11.4关于Polyfill的注解
随着 ECMAScript 5和HTML 5的特性开始在各种浏览器中的实现，JavaScript polyfills（也称为 shims）变得流行起来了。一个polyfill是指一种功能的模拟，这些功能在新版本的浏览器中已经有完备定义并原生实现了。例如，ECMAScript 5为数组增加了forEach（）函数。该方法可以在ECMAScript 3中模拟，以便在老版本的浏览器中如同新版本一样使用。polyfills的关键是它们模拟的原生功能要以完全兼容的方式来实现。因此在有些浏览器中存在了这些功能，所以有必要检测不同情况下它们的处理是否符合标准的方式。为了达到目的，polyfills经常会给非自己拥有的对象新增一些方法。我不是polyfills的粉丝，不过对于别人使用它们，我表示理解。相比其他的对象修改而言，polyfills是有界限的，是相对安全的。因为原生实现中是存在这些方法并能工作的，有且仅当原生方法不存在时，polyfills才新增这些方法，并且它们和原生版本方法的行为是完全一致的。
polyfills的优点是，当只支持浏览器的原生功能时，它们非常容易删除。如果你选择使用某个polyfill，你自己做好严格审查。要保证它的功能和原生的版本尽可能的近似，多检查一下这种库代码有单元测试并严格验证了这些功能。polyfills的缺点是，它们可能没有精确地实现它们（原生浏览器环境）所缺失的功能，从而给你带来的麻烦比缺失的功能要多得多。
方法封装了从DOM中删除一个元素的操作，屏蔽了开发者要访问该元素父节点的需求。
从JavaScript的可维护性而言，门面是非常合适的方式，自己可以完全控制这些接口。你可以允许访问任何底层对象的属性或方法，反之亦然，也就是有效地过滤对该对象的访问。你也可以对已有的方法进行改造，使其更加简单易用（上段示例代码就是一个案例）。底层的对象无论如何改变，只要修改门面，应用程序就能继续正常工作。
门面实现一个特定接口，让一个对象看上去像另一个对象，就称作一个适配器。门面和适配器唯一的不同是前者创建新接口，后者实现已存在的接口。
11.4关于Polyfill的注解
随着 ECMAScript 5和HTML 5的特性开始在各种浏览器中的实现，JavaScript polyfills（也称为 shims）变得流行起来了。一个polyfill是指一种功能的模拟，这些功能在新版本的浏览器中已经有完备定义并原生实现了。例如，ECMAScript 5为数组增加了forEach（）函数。该方法可以在ECMAScript 3中模拟，以便在老版本的浏览器中如同新版本一样使用。polyfills的关键是它们模拟的原生功能要以完全兼容的方式来实现。因此在有些浏览器中存在了这些功能，所以有必要检测不同情况下它们的处理是否符合标准的方式。为了达到目的，polyfills经常会给非自己拥有的对象新增一些方法。我不是polyfills的粉丝，不过对于别人使用它们，我表示理解。相比其他的对象修改而言，polyfills是有界限的，是相对安全的。因为原生实现中是存在这些方法并能工作的，有且仅当原生方法不存在时，polyfills才新增这些方法，并且它们和原生版本方法的行为是完全一致的。
polyfills的优点是，当只支持浏览器的原生功能时，它们非常容易删除。如果你选择使用某个polyfill，你自己做好严格审查。要保证它的功能和原生的版本尽可能的近似，多检查一下这种库代码有单元测试并严格验证了这些功能。polyfills的缺点是，它们可能没有精确地实现它们（原生浏览器环境）所缺失的功能，从而给你带来的麻烦比缺失的功能要多得多。
