可简单避免的三个JS发布错误

Web应用程序开发是倾向于在客户端运行所有用户逻辑和交互代码，让服务器暴露REST或者RPC接口。编译器是针对JS作为一个平台,第二版ECMAScript正是考虑到这一点在设计。客户端框架例如Backbone, Ember和Require鼓励创建功能丰富的应用程序，不仅有丰富的代码，而且各个组件，组件与数据之间有很多相互作用。

这真的很好，或许还能产生一些优秀的用户体验，但是毫无疑问的是，这是很难开发web应用程序和web页面。

根本原因是在互联网上服务你的代码和数据，运行在一些随机的浏览器上，在javascript中，这是一种你需要特别小心的语言，它是一个完全缺乏代码部署的平台。而且它不会很快就得到改善。我觉得如果星际迷航是现实生活，那么Jean-Luc Picard队长每隔一段时间不能打架的原因是他仍然是克林仪表板加载。

我想强调的是三个相对常见的错误和容易的解决方案，并且谈谈一些我们遇到的从ReadyForZero学到的特别的事情。

剥离“缓存清除”头信息

你可能使用CDN来缓存静态资源，这当然是合理的。如果你向服务器请求非缓存的资源（比如在AWS<Amazon Web Service>端使用"custom-origin"将文件指向真实的网络站点），这就需要小心了。你可能会在部署新版本的文件后添加一段缓存清除的字符串（头信息）到文件名上来达到这个目的，这样你的文件名看起来是这样的：

http://example.com/js/main__V0123456789abcdef__.js

这很容易做到，你可以选择任意的Hash算法来生成一段指纹信息作为这个字符串，这样它就会随着文件内容变化而变化。当新的url被引用时，它不可能被缓存，这样就可以获取到服务器上的新版本。错误就发生在这里。在网络上有很多都建议剥离“缓存清除”头信息，而是让你的服务器直接提供新版本的文件。如果你有多台服务器集群这可能导致你的站点上不同文件（如：html、js）的版本不一致（如js已更新但是html（从另一台服务器请求）仍然是旧的），不仅如此，更严重是它很容易导致CDN缓存了错误的版本。这个错误是这样发生的：

·初始阶段，所有的服务器都是HTML1 和JS1.

·服务器A重启了，并提供HTML2和JS2.

·一个客户端向CDN请求main__V2__.js，这个时候这个文件是新的所以CDN上没有缓存。

·CDN把这个请求传给了你设置的custom origin， 碰巧这个请求发到了服务器B上。

·服务器B剥离了“缓存清除”字符串并返回旧的版本。

·CDN把旧版的的文件当新的缓存了。

这件事情考虑起来很简单明了，但是盲目的听从网络上的建议很可能导致错误。更糟糕的是在你这看起来一切都是好的你根本不知道发生了错误，但是其它地区的用户使用了不同CDN很可能缓存了错误的版本。解决方案是不要剥离“缓存清除”字符串并将静态资源存放在能够正确支持各个版本的地方。

2. 处理庞大的JS炸弹

每个人都知道，我们需要压缩我们的javascript文件，并把它们连接在一起。但是盲目地这样做并非明智之举。如果连接的文件很大，那么更有效的方法就是并行化。另外，如果你需要频繁的修改文件的某一部分，你可能会导致很多地方失效，而文件很大部分却没有被修改过。

如果把频繁修改的部分分离出来，那么就可以解决两边的问题。我建议使用require.js - 它可以实现对你的javascript的真正的依赖关系管理，而且第一次使用的时候，设置很简单（稍后添加会很痛苦），而且可以帮助你理解和管理依赖关系，包括一些高级选项，例如异步载入。

需要注意的：require.js会等待一段时间后会放弃载入资源，这个可以通过指定waitSeconds选项实现，这个选项的默认值似乎7秒，它依赖于你的用户在哪里（例如：手机），可以是很短的时间。

3. 没有汇总错误事件

你不能只让你的javascript上线使用，而不关心它的运行情况。你不可能测试每一个浏览器和每个用户的状态组合。另外，不同的载入时间可能导致怪异的状态。所以，建立某种反馈机制来判断你的用户是否遇到错误，变得十分重要。这很简单，你只需通过指定一个全局错误处理程序，收集错误，并发送会服务器。以下是一个例子：

window.onerror = function(message, url, linenumber) {  


    sendToServer({message: message, line: linenumber, url: url});  


} 

棘手的部分是，很多时候会出现一些非0的错误，因为用户可能安装了各种怪异的插件或者其他。所以你需要跟踪稳定的状态到底是什么，还有是否有任何的偏差。

ReadyForZero，我们在顶层捕获onError事件，并把它们发送会服务器，然后生成一个日报，汇总多少个用户发生了错误，和这些错误发生在哪里。我们发现很多时候，错误消息并不足够，所以我们同样需要从我们的事件系统回传最后几个事件。通过分析用户最近触发的Backbone或者JQuery事件，对于获取当时用户触发错误时候的上下文信息，有很大的帮助。

垂手可得的改进

令人沮丧的是下面这些点不是我们必须担心的。公司更应该关注在产品上，快速高质量地把它们弄出来。但是请记住如果这些垂首可得的改进获得实施，你将能更专注于大动作上。

人们总是被一些琐事纠缠住花费了大量时间，但是仅仅让你的应用正常运行就能获得大的成长。

1，你的客户端代码有没有内存泄露？你确定吗？你是怎么知道的？

2，在ReadyForZero[注1]我们有很多聪明的人们致力于推动这门艺术。