あいかわらずWebサイトの制作に絡んでおりますが、最近はめっきりJavaScriptを扱うことがどんどん多くなってきました。

  • パララックスなどのスクロールを使ったアニメーション表現
  • 複雑なロジックでの見積コンテンツ
  • 診断コンテンツ
  • Ajax主体のショッピングサイト
  • etc..

Flashの衰退に伴って複雑なプログラムも少なくないのが現状です。JavaScriptを開発していてよく使うデバッグツールとしては、

  • FireFoxのFirebug
  • GoogleChrome開発ツール(これよく使う)
  • Safariの開発ツール
  • そのたブラウザの開発ツール

などなどたくさん有りますが、そういったツールを使っても複雑になればなるほど、完成に近づけば近づくほどにバグを発見するのは至難の業です。

(プログラミングスキルが足りないのも一つの原因ですが..)
規模が大きくなるのにつれて、JavaScriptのコード同士、HTMLのDOMなどの依存がひどくなり、サジを投げたくなることもあります。
そこで、規模が大きくなってもサジを投げないように、

  • 永続的なプログラムの保守性
  • デバッグの工数の軽減
  • コードの品質の向上

を考えました。

そこで出た一つの方法は、プログラムのモジュール化です。
外部プログラムに依存せずに一つの機能だけを持ったプログラムを多く書くようにしました。
１つのプログラム(1ファイル)を100〜200行のシンプルな形で依存が極力ない形で実装をしていくことにしたところ、
バグがあった場合でも１つ１つのプログラムがシンプルなので、入力の値を変化させたりが容易になり、ある程度効果がありました。
(メインのライブラリでjQueryを使うことがほとんどなので、jQueryプラグインの形で書くことが多いです。)

しかしモジュール化を行ってシンプルなプログラミングをしても、どうしてもバグは出てきてしまいます。納品前に実際のデータでのテストなどを進めて行く段階でのデバッグがどうしてもまだ多かったのです。
この段階でのデバッグが多いことは以下のような事につながりました。

  • 納期の遅れ
    この段階ではスケジュールが詰まっている事が多く、デバッグのスケジュールが予定外となっている。
  • バグ発覚→修正の繰り返し
    イテレーションを繰り返し品質を上げることは悪いことでは無いのですが、ういうプログラムの部分でなくて、ユーザビリティー、ユーザエクスペリエンスの等のコンテンツの品質を高めることに時間を使いたい。
  • スケジュールが読めない、目処が立てにくい
    まずバグがあったら原因調査→対応方針決定→PMに確認→修正など手順も多くなり、時間が読めなくなることも多い。

どうにか完成させる事(締切りに間に合わすこと)だけが重要になり、リリース後に改善という言い訳の元に完成して放置されるetc.

最終段階では、上記の用にプログラムの品質向上とかでなく、もっと本質的なコンテンツの質の向上に使いたい！！のです。
JavaScriptの品質を上げてコンテンツの品質を上げていくためにも、他の言語の用にJavaScriptでも「テスト開発駆動(TDD)」を本格的に導入していこうと考えました。