WEB+DB PRESS Vol.70にClosure Compiler/Linterの記事を書きました

連載「JavaScript活用最前線 ── 大規模開発の現場から」第3回目の記事を書きました。

今回はClosure CompilerとClosure Linterの紹介と、コンパイル時の警告をもとにコードチェックツールとして利用する方法を解説しました。
最近は割とClosure Compilerを使ってる人が増えてきたような印象がありますが、コードチェックにまで活用している例はあまり見ないので参考になれば嬉しいです。

これはあくまで僕が経験したケースですが、JavaScriptで実際に複数人で大規模なコードを書いてみると、2〜3万行くらいまでは割と頑張ればなんとかなります。でもそれ以上の規模になってくると、型のぶれが抑えられなくなってきます。型のぶれとは、数値を期待してるとこに数値文字列がきて足し算したら文字列連結になっちゃたとか、配列を期待してたら添え字付きのオブジェクト(!!)が入ってきて配列用のメソッドが動かないとか、そういうやつです。

そうすると多少型がぶれても動くコードを書くようになります。
簡単に書くとこのくらいで、

function hoge(num) {
  var number1 = parseInt(num, 10);
}

funktion fuga(arr) {
  var array1 = arr || [];
}

ちょっと複雑になるとこういうものも。

function foo(obj) {
  if (isArray(obj) {
    ...
  } else if (isObject(obj)) {
    ...
  } else {
    ...
  }
}

このようなことをやっていると一応ちゃんと動くんですが、バグは必ずこういう処理が漏れてる箇所で発生するんですよね。

そうして発生したバグをしばらく潰していると、ふと「あれ、これ詰んでね？」と思うようになります。いや、思いました。どれだけ型に対して慎重にコードを書いても必ず型の考慮漏れは出てくるし、書いてるのは自分だけじゃないから書き方も統一できないし、このまま一生後手後手で型エラーと戦うのかという不安感はいやなものです。

そこで取った方法が、Closure Compilerを使ったコンパイル時チェックです。
紙面ではClosure Compilerの基本的な使い方から、コードチェックツールとしての利用方法、継続的インテグレーションに組み込んで綺麗なコードを維持する方法までを解説しています。

Closure Compilerを使ったコードチェックを導入することで、型エラーに対する不安をほぼなくすことができました。ついでにAPIが返すデータ構造の設計がよろしくないとこが見つかったり、コンパイル後のパフォーマンスが向上したり、身長が5cm伸びたりしました。

WEB+DB PRESS Vol.70は本日発売です。Webアプリ開発でJavaScriptを書く方や、きちんとしたJavaScriptを書きたい方は、ぜひ読んでみてください。

WEB+DB PRESS Vol.70