肩こり歴20年のagoです。
社内でもjQueryを使う人間が増えてきたので、jQueryを使う人が陥りやすい罠をいくつかあげてみたいと思います。 （私が過去にはまったり、今はまっている罠です）
1 グローバルの名前空間を使わない
jQueryはwindow objectの汚染が少なくほかのライブラリとの共存が行いやすいですが、特定のサイト向けに開発する場合window objectを使用してもそれほど問題は発生しません。
しかしjQueryに慣れるとwindow objectの使用をいかに避けるかを考えるようになり、jQueryと関係ないfunctionや変数まで$.hogehogeに実装しようとしてしまいます。
これはwindow objectの代わりにjQuery objectを汚染しているだけなので、素直にwindow objectを使用したほうが普通に実装しやすいでしょう。
2 .prototype拡張を避ける
1と同じ理由から.prototype拡張を必要以上に避けがちになりますが、自分の把握できる程度であれば.prototypeを使用した方が実装が容易になる場合が多いです。
3 とりあえずjQuery拡張にする
名前空間の汚染を気にするあまり何でも$.fnに納めてしまいがちですが、jQueryを使用しないのであれば普通にfunctionを定義しましょう。
4 何でも一行で書こうとする
$('#aaa')
.find('.bbb')
.filter(':first')
.addClass('head')
.end()
.end()
.parents('tag')
.children(':first')
.addClass('head')
.end()
.end()
.end()
;
method chainをつなげると中間変数も少なくなるしDOM構造との対応がついて書きやすいのですが、途中の状況を把握しづらくデバッグが難しくなるので適当なところで変数に受けましょう。
method chainを多用する場合、以下のエントリーも参考になるかもしれません。
8行でjQueryのデバッグが楽になるjQuery.pの紹介
5 無理にselectorで表現しようとする
$(':not(:first):contains("hoge")')
書き方によってはCSS Selectorの方が早い場合もありますが、無理なselectorは予想外の要素に一致したり可読性がおちたりであまりいいことはないです。
selectorの量は適当な範囲に押さえ、適度に.findや.notなどのTraversing APIを混ぜましょう。
6 必要以上にブラウザ互換を取る
通常のweb serviceをつくるためにブラウザ互換を取るのはいいんですが、Vista SidebarやiPhone向けサービスまでブラウザ互換を気にするのはやり過ぎですよね。
ターゲットブラウザが明確な場合、思い切って非互換機能も使用してみましょう。
7 jQueryに存在しない機能を使わない
jQueryのサポート外でも有益な機能はいろいろあります。
特にイベントは結構サポートされていないものが多いので、どんなものがあるか把握だけでもしておいた方がいいでしょう。
List of events - ESW Wiki Javascript - Event compatibility tables
ただ、jQueryが未サポートの機能はブラウザ互換がない可能性が高いので注意しましょう。
8 jQuery.funcに違和感を感じない
jQuery object($)はjQuery()で実行もできるし、jQuery.browser等の独自propertyもついてるfunction objectになります。
jQueryを使用してるとあまり違和感がないのですが、通常であればobjectの中でmethodとpropertyに分けたほうが可読性は高くなると思います。
