可简单避免的三个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]我们有很多聪明的人们致力于推动这门艺术。

相关推荐