迷いに迷う「次の一手」
最近，ソフトウェア開発の難しさを特に感じている。本当にソフトウェア開発は難しく，そして複雑だ。ことJavaに関しては，年々その複雑さが増すばかりで，EoDなど遠くの彼方な気がしてならない。それなのに，どこもJavaを選択した案件ばかりである。 しかも，技術的に複雑になってきているのに，プログラマのレベルは年々下がってきている気がする。最新技術の複雑さに追随できているプログラマなど，ほんの一握りである。多くのプログラマは，自ら技術の習得に励むような姿勢を見ることはできず，目の前の案件の仕様を何となく理解し，何となくプログラムを記述しているだけだ。 こんな状況を嘆き続けながら，でも次の一手を考えなければならない。 結局のところ，以下の要因を満たすものは何なのか？，を考えればいいのかな。
-
シンプルな開発スタイル
-
UI構築の容易さ
-
分担作業の容易さ シンプルな開発スタイルとは，SOAに代表される疎結合技術とプロトコルの標準化の恩恵を受けることによって，とにかくソフトウェアの構築をパーツの組み合わせのみで仕上げることができるようにするのを目指すべきだろう。アプリケーションのレベルにまで落とせば，それはDIを中心とした開発ということになる。けれど，DIは，やはり裏方というか，存在を感じないミドルウェアのようなものにならないといけない。そのために，規約重視指向や自動生成などを駆使してXML地獄から解放されることを目指すのが現在の近道なんだろうけど，コードや設定ファイルの生成すらもIDEとして完全に隠されないと，シンプルという冠は付けられない。そういった上で，Java Studio CreatorやVisual Studioなどといった高級なIDEが次々と出てこないと，将来はない。 シンプルさを追い求めるためには，コンポーネント指向とイベント指向のプログラミングスタイルの復権は必須である。上流の設計において，画面の設計から始めることが，開発者にとっても顧客にとっても最もわかりやすい。やはり，ソフトウェアはユーザインタフェース駆動な開発が最も適していると思う。プログラマにアーキテクチャの根底をなすクラス構造を理解させることなど不可能だし，そもそも「このボタンをIDE上でダブルクリックして，できたイベントハンドラに業務処理を書け」だけでプログラマに対する指示は十分なはずだ。Webアプリケーションの普及はもはや止める術はないだろうから，Ajax対応な標準コンポーネントフレームワークの策定と，Ajax対応UIコンポーネントの豊富な登場，そしてイベントドリブンな開発を促進することが可能なIDEが出てこないと，将来はない。 更に，イベント指向な開発が可能になるということは，コンポーネント指向な開発が前提となるため，UIの構築は自然と敷居が下がってくるはずである。大元のHTMLのデザイン的土台は，デザイナに今まで通り頑張ってもらえば良い。HTMLというキャンパス上にAjaxコンポーネントをペタペタ配置し，コーディングレスなUI構築が可能となるIDEの登場がないと，将来はない。 そして重要なのが，Javaはコンパイラによる型チェックが厳格であること。これがチーム開発では大きな壁としてのしかかる。近年ではCVSやVSSすらまともに使いこなせないプログラマも非常に多い。自分のコードが他人に与える影響を把握できないのだ。コンパイルエラーが出るコードがCVSにコミットされてしまうことも，僕的には信じられないのだが，日常茶飯事。一瞬にしてアプリは全開発者のPC上でコンパイルエラーが発生したり，例外の発生などで起動しなくなる。いとも簡単に開発はストップしてしまうわけだ。プロジェクトやコードをうまく分割すればいいじゃん，と思うだろうが，そこまで準備が整った上で開発を始めることができる余裕なプロジェクトなど今日では存在しない。それはきれい事である。 それを打破するためには，業務の根幹をなすトランザクション処理は厳格に開発し，イベントハンドラからトランザクション処理を呼び出してアプリケーションを構築する部分はLL（Lightweight Language），つまりスクリプトで開発するという手法が有効だろう。JavaScriptでも良いし，他の言語でも良い。ようは常にアプリケーションが起動可能な状態で開発が進められることが重要。自分のコードの他人への影響度を下げてあげることが，最近の現場に求められていることなのだ。この場合，スクリプトはサーバサイドで動作することになるので，Rhinoなどのスクリプトエンジンが非常に重要になってくる。そして，イベントハンドラ内でスクリプトによる開発が可能なアーキテクチャと対応IDEが登場しなければ，将来はない。 自分の今の考えをまとめるとこんな感じである。これらを元に，どんなアーキテクチャが好ましいかを考えてみると，下図のようになった。
これって，J2EE標準に限りなく近い。
OSSの乱立に伴い，そして今までの開発に対するアンチラーゼとなるプロダクトの乱立もあり，次の一手は何が好ましいのか，迷いに迷っていた。しかし，上記のようなまとめを自分で行ってみると，自ずと目指すべき姿が見えてきた。
上図のアーキテクチャは，Java Studio Creatorを代表とするJSF対応IDEであればほぼ網羅されるだろう。しかし，そこにLLを取り込むということは，まだ自らが手を下さなければならない領域だ。さらに，JSF対応IDEではバックエンドのコンポーネント群の開発は領域外なので，別の実装環境が必要になってくる。
・・・と，ここまで書いてふと思う。うーん，結局はSunが提唱する技術トレンドに乗っとけばいいってことなのかな。
