可配置化 一旦我把所写的JavaScript代码发布到这个世界上，就有人想改动它，通常是人们想让它完成一些它本身完成不了的任务—但通常也是我写的程序不够灵活，没有提供用户可自定义的功能。解决办法是给你的脚本增加一个配置项对象。我曾经写过一篇深入介绍JavaScript配置项对象的文章，下面是其中的要点：
通常情况下这是你编程过程中的最后一步要做的事情。我把这些集中表现在了一个例子里： “Five things to do to a script before handing it over to the next developer.” 实际上，你也希望你的代码能够让人们很方面的使用，并且根据他们各自的需要进行一些改动。如果你实现了这个功能，你会少收到一些抱怨你的脚本的人发送给你的让你困惑的邮件，这些信件会告诉你，有人修改了你的脚本，而且很好用。 与后台交互在这么多年的编程经历中，我所领悟到的一个重要的事情就是，JavaScript是一个很优秀的开发界面交互的语言，但如果用来处理数字或访问数据源，那就有点使不上劲了。 最初，我学习JavaScript，是用来替代Perl的，因为我很讨厌非要把代码拷贝到 cgi-bin 文件夹下才能使Perl运行。后来，我明白了应该使用一种后台工作的语言来处理主要的数据，而不能什么事情都让JavaScript去做。更重要的是我们要考虑安全性和语言特征。 如果我访问一个Web service, 我可以获取到JSON-P 格式的数据，在客户端浏览器里我把它做各种各样的数据转换，但当我有了服务器时，我有了更多的方法来转换数据，我可以在Server端生成JSON或HTML格式的数据返回给客户端，以及缓存数据等操作。如果你事先了解了并准备了这些，你会长期收益，省去了很多头疼的时间。编写适用各种浏览器的程序是种浪费时间，使用工具包吧！ 在我最初开始搞Web开发时，在访问页面时，究竟是使用 document.all 还是使用 document.layers 的问题上痛苦的挣扎了很久。我选择了 document.layers，因为我喜欢任何层都是自己的document的思想 (而且我写了太多的 document.write 来生成元素)。层模式最终失败了，于是我开始使用 document.all。当Netscape 6 公布只支持 W3C DOM 模型时，我很高兴，但其实用户并不关心这些。用户只是看见这种浏览器不能显示大多数浏览器都能正常显示的东西—这是我们编码的问题。我们编写了短视的代码，只能运行在当前的环境下，而不幸的是，我们的运行环境却在不停的改变。 我已经浪费了太多的时间来处理对各种浏览器各种版本兼容的问题。善于处理这类问题提供了我一个好的工作机会。但现在我们不必在忍受这种痛苦了。 一些工具包，例如 YUI, jQuery 以及Dojo 都能够帮我们处理这类问题。它们通过抽象各种接口实现来处理浏览器的各种问题，像版本不兼容，设计缺陷等，把我们从痛苦中解救出来。除非你要测试某个Beta版的浏览器，千万不要在自己的程序里添加修正浏览器的缺陷的代码，因为你很有可能当浏览器已经修改了这个问题时，你却忘了删除你的代码。 另一方面，完全依赖于工具包也是个短视的行为。工具包可以帮你快速的开发，但如果你不深入理解JavaScript，你也会做错事。 |
