项目上线后，遇见一个很诡异的bug. 不断有用户反馈有问题，但开发和测试折腾了好久，都没找到重现条件。直到有个热心的用户跑过来，在用户的电脑上才发现问题所在：Flash版本过低，在js的某处判断了flash的版本，之后进入的代码分支中有这样一句：

YAHOO.util.Event.on(vipPopup, 'error', function () {...});

vipPopup在此处未定义，因此导致了出错。一旦找到出错点，解决起来就快了，不多说。

这问题让我想起一个一直想总结但一直没时间去总结的话题：如何让编写鲁棒的JavaScript代码？

鲁棒（Robust音译）的定义是：放在正确的环境能得到预期的结果，放在复杂的环境下也不会出错。很多JavaScript开发者还停留在裸写代码的时代，同时业界缺乏便捷低廉的前端测试方案，这导致项目上线后，某些bug在特定环境下才能触发，结果后续的bug定位就非常麻烦了。如果我们能在开发阶段，就让JavaScript代码鲁棒点，这样，即便测试覆盖不到某些分支，也不会因为异常而导致整个js代码坏掉。下面是我的一些经验：

一、养成良好的编码习惯。良好的编码习惯有两个来源：一是自己的实践、摸索和经验的沉淀，二是他人的经验，比如阅读经典书籍，看优秀的代码。《重构：改善既有代码的设计》是一本绝好的书，无论是编译语言还是脚本，我们都应该尽量去除代码的坏味道，用胃去写，用鼻子去闻，提升自己的敏觉度。举一个常见的卫语句使用场景：

就这么简单，只要有这个意识，养成了编码习惯，很自然的就能让你的代码更鲁棒健壮起来。《重构》等经典好书籍，同样适合前端开发，不要有畏惧心理，只要我们去琢磨去思考，就能运用到JavaScript程序中来。

好的编码习惯的培养，还需要多思多想，不断地从实践中总结得来。比如构建一些js的基础类库，就得非常仔细地考虑暴露的API. 举个例子：一个方法的返回值是Array, 就得考虑，返回值为空时，应该返回空数组还是null. 大部分情况下，返回空数组是合理的选择，因为调用处很可能是个循环语句。

或许在不久的将来，我们能看见《Refactoring to JavaScript》这类书籍的问世。当前，多读一些经典好书，总不会错的。

二、熟悉所用的框架。无论选择了哪个框架，抑或公司自己开发了一套框架，在使用时，一定要尽量做到知根知底，这能避免重复造轮子（框架里有的不必自己再去写，这一点，看似简单，要做到还真得费一番苦功夫），能让代码精炼优雅。比如上面提到的卫语句，并非任何地方都需要：

YAHOO.util.Event.on(el, 'click', function(ev) { if(!this) return; // do something
});

上面的卫语句就是多余的。因为YUI的实现里，对传入的参数el已经做了类似判断，保证el为null或空数组时，不会出错。

三、换用强劲的IDE辅助开发。EditPlus, EmEditor, Vim等文本编辑器的确很便捷，但当编写复杂的代码时，真的不建议继续用这些编辑器，是时候换成IDE了。看看Java和C#的开发环境吧，代码提示只是最低级的功能（其实这个有没有都无所谓），但IDE的重构和即时纠错等高级功能，对提高代码的质量是非常有帮助的。比如，如果上面的代码是用IntelliJ IDEA开发的，则在编写时就会有提示：

这样，直接就能将错误扼杀在编码阶段。对于Java等编译型语言来说，这是非常自然的开发过程。对于脚本语言来说，一个好的IDE，也是非常有必要的。保持绿灯常量，一天的心情都会好起来。

养成良好的编码习惯可以让我们的代码更健壮，熟悉所用的框架能让我们避免不必要的重复代码，强劲的IDE可以将错误直接扼杀在编码阶段。鲁棒的JavaScript不是梦，就在你手上。

评论 (0) All

登陆 还没注册？