October 22, 2005

Ajaxな制御とかActiveXとの通信とか、やれダイアログの制御や、それらが連携するデータ登録プロセスのフロー制御、クライアントサイドのValidation、フォームに関するDHTMLのUI制御とか組み込むのを、もろもろ他の人に任せていたら、JavaScript （+ VBScript）が1000行を超えてるわ、DHTMLとして使うHTMLフォームのブロックが、ほとんど同じで微妙に状態が違うだけのHTMLが４つも書いてあるわ最悪。

うーん、割と気軽に複雑な設計をしちまったのかなぁと、ちょっと後悔しています。

まだ世の開発者の多くは、JavaScriptは全然得意ではないと思っています。というか、僕も偉そうなことを言える立場ではありませんが、むしろ不慣れではないでしょうか？

JavaなどOO言語で、言語仕様によるコード文法の強制が確立している言語なら、開発者が正しいコード記述にキャッチアップするのは難しくないハズなのですが、JavaScriptは、まず自由な記述ができます。いわゆる普通のJavaScriptは、Flashでいうなら、タイムライン上に直接ActionScriptを記述するようなスタイルと言えます。また、データを出力する基本的なアプローチも違っていて、HTML + JavaScriptをサーバサイドで組み立てるときは、「クライアントサイドは、ただの文字列処理」感覚でソースコードを作りがちなんですね。

開発者のくせに同じようなHTMLを４つも書いてしまって、何の疑問も思わないというのは、HTMLやJavaScriptをJavaと同じようなプログラムだと認識していない証拠です。JavaならMVCを遵守したがるのに、HTML + JavaScriptに出力する文字を独立させようと意識しないのはおかしい話です。サーバサイドのスタンスで物事を考えているんでしょう。

JSPからは、できる限りデータだけを構築すべきだと思います。JavaScriptのオブジェクトや配列だけを構成し、画面の構築はJavaScriptの仕事にするべきです。

HTMLとサーバサイド出力が密結合してしまっていると、いざリファクタリングしようにも、サーバサイドからの出力コードがあっちこっちに埋まっているのは非常にやりにくい。これでは今一度、組み直すぐらいの決断が必要になってしまいます。

GoodPic.ComさんのAjax時代の、サーバ<->クライアントで協調するMVCフレームワークを見て、このネタを書く気になったのですが、確かにクライアントサイド実装のテンプレートエンジンやデータロジックなど各部を自動化してくれるフレームワークを使って、強制的にMVCを切り離すことが重要だよなぁと思っています。

ただ、自分としては今はまだフレームワークに頼るほどではないけど、基本的なプログラミングの仕方は変わってほしいというのが、今、JavaScriptを書くエンジニアに意識してほしいことです。少々ベタでも良いから、OOなJavaScript記述を意識して、少しでも効率の良いコードを書くことを実践するようにしてほしい。

僕が強烈にほしいと思っているのは、参考にすべきJavaScriptのコードパターンをまとめた本です。単純に世の中に出回っているフレームワークのコードを読めば学べるとは思いつつ、それはそれとしてバイブルとすべき文法本がほしいところです。

僕もHTML + JavaScriptにおいて、UIとロジックの切り離しのコードは全然できていなかったりします。いろいろUI制御があると、直接、ロジック内から操作する方が楽ですから、油断するとすぐUIに依存したスクリプトを書いてしまいがちだったりします。

しかし、Ajax時代にその10行を楽すると、結局、1000行に繋がってしまうということがよくわかりました。でもAjax時代のJavaScript記述の意識も持っていない開発者に口頭だけでOO的JavaScript記述を意識させるのは難しいと思っていて、ちょっと面倒でも効率よく、ソースコードをまとめる意識がもてるようになって、オライリーよりも読みやすい「ちゃんとしたJavaScriptを書けるようになる本」をどこかの出版社で作ってもらえませんでしょうかねぇ。