本书的第二个部分总结了有关编程实践相关的内容，每一个章节都非常不错，捡取了其中5个章节的内容。对大家组织高维护性的代码具有辅导作用。
5个章节如下——
一.UI层的松耦合
二.避免使用全局变量
三.事件处理
四.将配置数据从代码中分离出来
五.抛出自定义错误
一、UI层的松耦合
如果两个组件耦合太紧，则说明一个组件和另一个组件直接相关，这样的话，如果修改一个组件的逻辑，那么另外一个组件的逻辑也需要修改。比如，有一个名为error的CSS类名，它是贯穿整个站点的，它被嵌入到HTML之中。如果有一天你觉得error的取名并不合适，想将它改为warning，你不仅需要修改CSS还要修改用到这个calssName的HTML。HTML和CSS紧耦合在一起。
当你能够做到修改一个组件而不需要更改其他的组件的时候，你就做到了松耦合。当一个大系统的每个组件的内容有了限制，就做到了松耦合。本质上讲，每个组件需要保持足够瘦身来确保松耦合。组件知道的越少，就越有利于形成整个系统。有一点要注意：在一起工作的组件无法达到“无耦合”。在所有系统中，组件之间总要共享一些信息来完成各自的工作。这很好理解，我们的目标是确保对一个组件的修改不会经常性地影响其他部分。
下面我用一个图来来简要解释HTML/CSS/JavaScript三者之间如何做到松耦合——
二、避免使用全局变量
全局变量所带来的危害在这里就不说了，直接说说如何避免使用全局变量。
1.单全局变量
“单全局变量”的意思是所创建的这个唯一全局对象名是独一无二的（不会和内置的API产生冲突），并将你所有的功能代码都挂载到这个全局对象上。因此每个可能的全局变量都成为你唯一全局对象的属性，从而不会创建多个全局变量。
1> YUI定义了唯一一个YUI全局对象
2> jQuery定义了两个全局对象，$和jQuery。只有在$被其他的类库使用了的情况下，为了避免冲突，应当使用jQuery
3> Dojo定义了一个dojo全局对象
4> Closure类库定义了一个goog全局对象
2.模块
如YUI模块及AMD模块（例子略）
3.零全局变量
有两种情况会使用这种情形：
1> 所有所需的脚本都会合并到一个文件
2> 代码短小且不提供任何接口
/*
* 这段立即执行的代码传入了window对象，因此这段代码不需要直接引用任何全局变量。
* 在这个函数内部，变量doc是指向document对象的引用，只要是函数代码中没有直接修改window或doc且所有变量都是用var关键字定义，
* 这段脚本则可以注入到页面中而不会产生任何全局变量。
*/
(function(win) { var doc = win.document; // 在这里定义其他的变量 // 其他相关代码 })(window);
三、事件处理
我们习惯了使用最直接的方式去定义事件，如
addListener(element, 'click', function() {
var popup = document.getElementBuId('popup');
popup.style.left = event.clientX + 'px';
popup.style.top = event.clientY + 'px';
popup.className = 'reveal';
});
规则一、隔离应用逻辑
我们将上面的代码进行分解，首先隔离应用逻辑，将应用逻辑从所有事件处理程序中抽离出来的做法，所带来的好处：
1.提高应用逻辑代码复用性，说不定什么时候其他地方就会触发同一段逻辑。
2.测试时需要直接触发功能代码，而不必通过模拟对元素的点击来触发。如果将应用逻辑放于事件处理程序中，唯一的测试方法是制造事件的触发。
// 拆分应用逻辑
var myApp = { handleClick: function(event) {
this.showPopup(event);
}, /*
分离了应用逻辑之后，对这段功能代码的调用可以在多点发生，则不需要一定依赖于某个特定事件的触发。
*/
showPopup: function(event) {
var popup = document.getElementBuId('popup');
popup.style.left = event.clientX + 'px';
popup.style.top = event.clientY + 'px';
popup.className = 'reveal';
} }; addListener(element, 'click', function(event) {
myApp.handleClick(event);
});
规则二、不要分发事件对象
上述代码存在一个问题，即event对象被无节制地分发。它从匿名的事件处理函数传入了myApp.handleClick()，然后又传入了myApp.showPopup()。event对象上包含很多和事件相关的额外信息，而这段代码只用到了其中的两个而已。应用逻辑不应当依赖于event对象来正确完成功能，原因如下：
1.方法接口没有标明那些数据是必要的。好的API一定是对于期望和依赖都是透明的。将event对象作为参数并不能告诉你event的那些属性是有用的，用来干什么。
2.因此，如果你想测试这个方法，你必须重新创造一个event对象并将它作为参数传入。最佳方法是让事件处理程序使用event对象来处理事件，然后拿到所有需要的数据传给业务逻辑。例如myApp.showPopup()方法只需要两个数据，x坐标和y坐标。
var myApp = {
handleClick: function(event) {
this.showPopup(event.clientX, event.clientY);
},
/*
分离了应用逻辑之后，对这段功能代码的调用可以在多点发生，则不需要一定依赖于某个特定事件的触发。
*/
showPopup: function(x, y) {
var popup = document.getElementBuId('popup');
popup.style.left = x + 'px';
popup.style.top = y + 'px';
popup.className = 'reveal';
}
};
addListener(element, 'click', function(event) {
myApp.handleClick(event);
});
这样就很清晰地看到myApp.showPopup()所期望的传入的参数，并且在测试或代码的任意位置都可以很轻易地直接调用这段逻辑。如，myApp.showPopup(10, 10);
当处理事件时，最好让事件处理程序成为接触到event对象的唯一的函数。事件处理程序应当在进入应用逻辑之前针对event对象执行任何必要的操作，包括阻止默认事件或阻止事件冒泡，都应当直接包含在事件处理程序中。这样很清晰地展现了事件处理程序和应用逻辑之间的分工。
var myApp = {
handleClick: function(event) {
// 假设事件支持DOM Level2
event.preventDefault();
event.stopPropagetion();
// 传入应用逻辑
this.showPopup(event.clientX, event.clientY);
},
/*
分离了应用逻辑之后，对这段功能代码的调用可以在多点发生，则不需要一定依赖于某个特定事件的触发。
*/
showPopup: function(x, y) {
var popup = document.getElementBuId('popup');
popup.style.left = x + 'px';
popup.style.top = y + 'px';
popup.className = 'reveal';
}
};
addListener(element, 'click', function(event) {
myApp.handleClick(event);
});
四、将配置数据从代码中分离出来
配置数据，如
1.URL
2.需要展现给用户的字符串
3.重复的值
4.设置（比如每页的配置项）
5.任何可能发生变更的值
我们时刻要记住，配置数据是可以发生变更的，而且你不希望因为有人突然想修改页面中展示的信息，而导致你去修改JavaScript源码。将配置数据抽离出来意味着任何人都可以修改它们，而不会导致应用逻辑的错误。同样，我们可以将整个config对象放到单独的文件中，这样对配置数据的修改可以完全和使用这些数据的代码隔离开来。
var config = {
URL: {
save: 'module/save',
remove: 'module/remove',
update: 'module/update',
list: 'module/list'
},
MESSAGE: {
empty: '输入内容不可为空',
success: '编辑成功',
error: '服务器错误，请稍后再试'
},
PAGE: {
startIndex: 0, // 开始索引
limit: 20, // 每页显示X条数据
currentPageNum: 1 // 默认当前页
}
};
五、抛出自定义错误
1.抛出错误
针对所有浏览器，唯一不出差错的显示自定义的错误消息的方式就是用一个Error对象。
2.抛出错误的好处
抛出错误陈述发生的问题，能够马上去调试。就像给自己留下告诉自己为什么失败的便签。
function getDivs(element) {
if (element && element.getElementByTagName) {
return element.getElementByTagName('div');
} else {
// 推荐总是在错误消息中包含函数名称，以及函数失败的原因
throw new Error('getDivs(): Argument must be a DOM element');
}
}
3.何时抛出错误
如果一个函数只被已知的实体调用，错误检查很可能没有必要（这个案例是私有函数）；如果不能提前确定函数会被调用的所有地方，你很可能需要一些错误检查。这就更有可能从抛出自己的错误中获益。
本书中提供了一些抛出错误很好的经验法则：
1> 一旦修复了一个很难调式的错误，尝试增加一两个自定义错误。当再次发生错误时，这将有助于更容易解决问题。
2> 如果正在编写代码，思考一下：“我希望[某些事情]不会发生，如果发生，我的代码会一团糟糕”。这时，如果“某些事情”发生，就抛出一个错误。
3> 如果正在编写的代码别人（不知道是谁）也会使用，思考一下他们使用的方式，在特定的情况下抛出错误。
4.throw和try-catch的区分
// 使用throw
throw new Error('123'); alert(1); // 不会执行
// 使用try-catch
try {
throw new Error('123');
} catch(e) {
alert(e.message);
// 在这里可以对错误进行处理，目的是从错误中回复
} alert(1); // 会执行
// 两者结合使用
function test() {
throw new Error('123'); alert(1); // 不会会执行
} function test2() {
try {
test();
} catch(e) {
// 对test调用抛出的错误进行处理
alert(e.message); //
// 错误恢复
}
alert(2); // 会执行
} test2();
总结：本篇随笔把这本书的第二个部分——编程实践，其中的核心部分抽取出来。这样，结合上一篇随笔（【读书笔记】读《编写可维护的JavaScript》 - 编程风格（第一部分）），完成对本书前两个部分的阅读总结。对第三个部分（自动化），也是最后一个部分，就不做总结了。
很不错的书，推荐博友们看看。细细品味一下。
最后，放入这本书的logo——
