また、Struts、Spring、Hibernateのようなフレームワークを利用してWebシステムを構築した場合、struts-config.xmlのほか、多数のXMLによる設定ファイルの記述が必要になるだろう。これらのXMLファイルは単なる設定ファイルという位置付けでよいのだろうか?
さらに、最新のJava SE 5.0あるいはEJB 3.0では、アノテーションと呼ぶメタデータ機能が利用できる。簡単に言うと、アノテーションとはソースコードに対してのコメントを記述するメタデータである。このメリットのひとつとして、アノテーションを利用することで、コンパイラがコンパイル時のチェックを行えるようになり、従来見つけづらいある種のエラー発見が容易になるのだ。
このアノテーションも通常のJavaプログラムの1行と同様に扱えばよいのだろうか……。
このように、最新の技術では、開発プロジェクトにおいてソフトウェア規模見積もりや、ソフトウェアの品質を試験密度やバグ密度で捉える際のベースとなるソースコード行数自体の捉え方そのものも、どのようにカウントすべきかという点で課題があるように思えるのだ。
Eclipseは、プラグインにより機能が拡張可能という大きな特徴を持つ。Eclipseだけで上記の課題が解決できるというわけではないが、このような機能拡張が可能なIDEが、エンジニア数(プロジェクトの規模)に左右されず無償で使うことができる意義は非常に大きい。
近い将来、開発者の開発環境がEclipseベースに統一され、かつ今の技術に即したメトリクスが標準化してプラグインとしても無償提供され、さらに算出したメトリクスが企業レベル(あるいは業界レベル)で共有できる仕掛けがEclipse上で実現されれば、その効果は計り知れない。
また、リファクタリング作業に着目して見ると、リファクタリングは重要な作業ではあるが、開発者側が顧客に対してリファクタリングに要する工数や費用を請求することは現状では困難だ。しかし、分析設計から試験にいたるすべてのソフトウェア開発工程の作業がEclipse上に統合されつつあるため、近い将来、プログラム構造の改善度合い/メンテナンス性の向上度合いあるいはパフォーマンスの向上度合いから「リファクタリングの効果」が計測や数値化、視覚化され、さらに業界全体での合意が形成されれば、顧客に対して工数や費用の同意を得られる可能性もあるだろう。
さらに夢のような(ちょっと怖い)話をすれば、Eclipse上で操作の記録を取ることで、プログラマ自体の能力や疲労度合いなどを評価や判定するプラグインも現れるかもしれない……。
そこまで行かないまでも今後もEclipseは、「Eclipse Foundation」の開発コミュニティーを通じて、パフォーマンスの改善や複数プログラミング言語への対応だけでなく、より大規模で複雑な開発やより拡張性の高いプラットフォームに向けて、さらにいっそう進化していくだろう。
活用次第で、日本企業にも大きな恩恵をもたらしてくれる。Eclipseがこれまでのソフトウェア開発に「革命」をもたらすのは間違いない。ぜひ開発にうまく活用して、日本のソフトウェア業界全体のレベルアップに結び付けていきたいものである。
Copyright © ITmedia, Inc. All Rights Reserved.