JSPはもうこりごり・・・

Written on Dec 18, 2005. Posted in Java

J2EEというエディションが登場する直前，JSPというものが登場することを知ったとき，僕はかなりウキウキしたものだ。当時僕は仕事でアプレットかサーバプログラム(その間はソケット通信!)ばかり書いていて，サーブレットは勉強中。サーブレット内でHTMLを文字列連結を頑張るのに「まじっすか」と思っていたときに耳にしたJSP。HTML内にJavaプログラムが書けて，動的コンテンツを埋め込める。そしてコンパイルは勝手にやってくれる。そんな便利なものが登場したら，世の中JSPさえあれば何でもできるじゃん，とさえ思っていた。

それから数年。もうJSPはこりごりである。

コンピュータ言語を使ったソフトウェア開発において，コンパイルという作業は非常に重要である。Javaの場合はバイトコードを生成する作業になるのだが，開発者にとってその変換はさして重視していない。開発者がコンパイル作業を行う動機のほとんどが，コンパイラによるチェックだろう。自分で書いたコードが文法的に間違っていないかどうか，使用している変数は宣言されたものか，呼び出しているメソッドが存在するかどうか，などがコンパイル作業によってチェックされる。もし間違っていれば，どこが間違っているかをコンパイラがエラーメッセージで教えてくれる。Eclipseにおいても，裏でコンパイラが自動的に実行されて，チェック結果を開発者にフィードバックしてくれる。

リフレクションを業務コードを書く実装者が使うことは基本的にあり得ないので，コンパイルさえ通れば，最低限の保証はされるわけである。

例えば，O/Rマッピングされるモデルクラスのプロパティを，仕様変更に伴い一つ削除しなければならない状況を考えてみる。Javaではgetterメソッドを削除することがプロパティの削除を意味する。getterメソッドをモデルクラスから削除し，その直後にコンパイルを行えば，それを呼び出している箇所はチェックで引っかかるので，影響範囲を把握することができる。

しかし，JSPはその範囲に入らない。

「」によるスクリプトレットでJavaコードをJSP内に記述していれば，JSPの事前コンパイルで上記の範囲内に入る。しかし，今日ではスクリプトレットは悪だという考えから，カスタムタグの使用が基本だ。上記のモデルクラスの例で言えば，jsp:beanタグやStrutsのタグライブラリ，JSTLタグライブラリなどを使って，モデルオブジェクトのプロパティの値をJSP内で参照する。この場合，値の取り出しはリフレクションなどを使って動的に行われるため，コンパイラによる事前チェックの恩恵を受けられない。

大規模になればなるほど，ViewとDAOとの距離は遠くなるし，モデルクラスのプロパティを実装者が全員把握していることは期待できない。モデルクラスのプロパティを削除することは，アプリケーション全体でもかなり影響範囲が大きい重要な修正だ。影響範囲を機械的に見つけることができず，しかも実行してみないとわからないという状態は，棒を持たずに綱渡りをするようなものだ。それでも試験作業がちゃんとしていて，リグレッションテストが確立されていれば安心だが，得てして試験工程は軽視されがちであり，正しい認識を持つ人は非常に少ない。たまたま動かしてみて「あ，プロパティがない」と気がつく状態が，残念ながら日常なのだ。

このような状況を回避するために，ViewHelperパターンの適用がまずは解決策として考えられる。JSPから取得するデータは，JSPや汎用カスタムタグから直接モデルオブジェクトにアクセスせずに，必ず何らかのクラスを作成してハードコードする。モデルクラスのgetterメソッドの呼び出し箇所をJavaコードとして記述する場所を作っておくことで，その変更あるいは削除時の影響範囲をコンパイルでチェックできるようにするのだ。

ViewHelperパターンは，JSPと1対1でViewHelperクラスを作成することもあるし，JSPと1対1でカスタムタグを作ることもある。どちらにしても，そのアプリケーション固有のクラス内でモデルオブジェクトにアクセスしてあげることで，保守性を高めることができるのだ。ただし，当然開発コードの量は増える。

最近ではCommonsのBeanUtilsなどを使って，オブジェクト間の値のコピーをさせてしまうことが増えてきている。記述するコードが激減するため，これをEoDと称して採用する人が多い。しかし，その代償をちゃんと考えての採用を行っている人は，ほとんどいないのではないだろうか。ただでさえバカプログラマが増殖されている近年のIT業界では，安易にコードの記述量を削減することを考えてはならないのではないか。JSPはその手軽さ故に，教育コストをかけずにWebアプリケーションが作れてしまう。その結果，出来てくるシステムは品質の低いものになりやすい。

プログラマの確保のし易さなどからJSPを採用することが当たり前だが，手軽さと保守性をちゃんと天秤にかけて，どのように実装者に対して安心感を提供してあげるかをまずは考えることが必要だ。その結果，コードの記述量やクラス数の増大になったとしても，後々の混乱を考えたら，そんなことは誤差の範囲だ。「怖くてもうコードを触れない」ということが言われないように，常に考えておくことが重要なのだ。

最近ではPOHPというキーワードが流行してきた。そしてPOHPのソリューションも次々と公開されてきている。POHPであれば，ほとんどの処理をJavaコードに記述することになるので，(BeanUtilsの使用などの問題は残るが)JSPのようなことは起きにくい。そろそろPOHPソリューションの採用を考えたいところだが，今はPOHP戦国時代であり，どれを採用するかは非常に迷うところだ。

ま，要は「堅強なシステムを作りましょう，そのためには目の前の手軽さに簡単に飛びついてはいけませんよ」ということである。