Strutsなどのフレームワークが必要な開発って

質問

JAVAを勉強している者です。
これまでJSPやサーブレットを使って、ある程度のシステムが作れる程にはなったのですが、フレームワークの事が気になっています。

少し「Struts」の勉強をしてみましたが、使いづらさと、表示画面への
柔軟性の無さなど、良い面が見つかりませんでした。

また、HTMLベースのソースコードも、フレームワーク独自の形があっ
たり、TomcatなどJAVA側のバージョンアップで不具合が生じる可能性
なども、耳にしました。

●そこで思ったのは、フレームワークを使う状況というのは、次の様な
時なのではと思っています。

・エンジニアのレベルが、時間さえあれば、一人でJSPやサーブレット
　を使ってシステムを作り上げる人と、「if」文や「for」文などの
　本当の基礎しか知らない人が混在した開発環境の時。

・開発プロジェクトで、開発人数が多く（十数人など）大規模なシステ
　ムで、柔軟性や工期短縮よりエンジニアの管理をする必要がある時。

●逆にこんな時には必要がないと考えています。

・携わる開発者が、一人でサイトを作れるレベルであり10人以内程に
　よる規模のシステム作成時。

・表示画面用のファイルと、他のプログラムファイルを分ける事
（MVC）を意識しすぎる事より、システム変更への柔軟性や、工期が
　早くなる事が分かった時。

・エンジニアのやりがいを引き出す為。

※個人的には、入力画面はともかく、出力結果などをMVCにこだわると
　あまり良い作成が出来ない気がしています。
　また、出力画面と処理用プログラムのファイルを分けた場合には、
　ソースの確認や編集が行いづらくなります。

　ただ、フレームワークを使わない時は、事前にエンジニアどうしで、
　一定の関数を使う事を基本条件にすると便利かもしれませんね。
（例えば、～本に載っている関数を使用する等）

　もし決まった関数以外で他の関数を使う時は、他のメンバーの了解
　を得る等のルールがあると良いかもしれません。
　（Eclipse関係の入門書とプラスαの関数で大抵の事は出来るのではと思っていますが．．．）

　多分こうした方が、フレームワークを使うより、エンジニアのやりが
　いも向上するし、結果的には効率も上がりそうな気がしています。

　また、上記のフレームワーク条件も、完全にそのようにしなければ
　ならないのではなく、状況や必要に応じて判断することが大切なの
　ではと思っています。

　もし、他にフレームワークのメリット・デメリットがありましたら
　教えていただけましたらと思っています。

回答No.2

kztk

こんにちは。

フレームワーク（枠組）という言葉通り、よい意味でも悪い意味でも「型にはめる」のが、フレームワークによる開発だと思っています。

　共通処理をフレームワークが吸収することにより、初心者が犯しやすいミスからシステムを守ることができ、プログラム毎の品質のバラつきを抑えることが出来ます。　「共通部品」のような考え方でもこれは可能ですが、共通部品はユーザープログラムから呼ばれる物なので、共通部品を使わずにコーディングされてしまうとアウトです。フレームワークではユーザープログラムがフレームワークから呼ばれるので、より安全です。
反面、熟練したエンジニアならばもっと効率的なコードを作成できるような場合には、フレームワークは足枷になると思います。

上記以外に、私は保守性の高さをメリットの一つに挙げたいと思います。
ここでいう保守性は「MVCを分離した方が保守性が高い」というような観点ではなく、（例えば）Strutsというフレームワークが世に広く普及しているという単なる事実による、保守性の向上です。
プロジェクト独自のフレームワークを採用している場合、新規要員を保守にアサインするに当たり、そのフレームワークの導入教育が必要となります。Strutsのようなメジャーなフレームワークを採用していれば、このような教育の手間をある程度削減することが出来ます。また要員の確保も「自社フレームワークでの開発経験がある開発者」よりも「Strutsベースの開発経験がある開発者」の方が容易です。

従って、下記の2つのケースについては私は一概には賛成できません。
開発後の保守も含めてトータルで考えるべきだと思います。

>・携わる開発者が、一人でサイトを作れるレベルであり10人以内程に
>　よる規模のシステム作成時。
>
>・表示画面用のファイルと、他のプログラムファイルを分ける事
>（MVC）を意識しすぎる事より、システム変更への柔軟性や、工期が
>　早くなる事が分かった時。

なお、下記については目的と手段が入れ替わってしまっているため、理由とすべきではないと思います。趣味の開発ならばよいですが。
>・エンジニアのやりがいを引き出す為。

下記のご意見については全面的に賛成です。
>また、上記のフレームワーク条件も、完全にそのようにしなければ
>ならないのではなく、状況や必要に応じて判断することが大切なの
>ではと思っています。

お礼

お返事ありがとうございます。

フレームワークを利用するかの判断は、開発内容や状況をよく考えて
行っていく必要がありますね。

回答No.1

kakusuke

Strutsは基本ＦＷです。
普通は、そのプロジェクトに合わせて、
ログ出力やＤＢ接続などの
色々なライブラリを組み込んだり、
トランザクション管理用の共通関数やベースクラス
を作成して使用します。

また、LookupDispatchActionクラスなど、
ＭＶＣでのＭ（モデル）を構築するのを簡便化するクラス
も用意されています。

.net開発のように
コンポーネント指向でなおかつ、
ＤＢ接続などが用意されていても、
ＷＥＢアプリを作成する場合、
トランザクションの管理は欠かせません。

StrutsやTarbineのような
オブジェクト指向型ＦＷは、
プロジェクトのルールを制約化するような
共通関数や基本クラスなどを作る基礎工事を行うため、
プロジェクトの方向性から外れたものを作るのは困難となるため、
工数がある程度読めますが、
自由度が少ないため、難易度の高いＰＧが出てくると、
その工数が跳ね上がります。

他方、ＶＢやDelphi、.net、ClickFW(Java)などの
コンポーネント指向型ＦＷは
個々のコンポーネントにある程度業務要件を満たすような
機能を持たせるため、
大量の本数および、工数が発生することでしょう。

メリットデメリットは仕方ありませんが、
アプリケーション開発において
いかに工期の短縮、簡便化を図るかということは至上命題です。
そこに能力を費やすことが重要なのだと思います。

お礼

お返事ありがとうございます。

開発案件で、ワークフローを使うべきかどうかの見極めは、難しいようですね。

私の知っていたワークフローを使った開発で、顧客との最初の提示より
遥かに長い工期になり、数年経っても完了しない状態が続いていました。

きっと、そのワークフロー内では解決が難しくなり、工数が跳ね上がっ
たのかもしれませんね・・・

開発においては、ワークフローを使うべきかどうかや、使うとしても何
処まで使うべきかなどを、開発内容や開発環境をよく考慮して行う必要
がありますね。

補足

すいません・・・
お返事へのお礼の内容なのですが、「ワークフロー」の部分は、「フレ
ームワーク」で置き換えて読んでください。
なんだか寝ぼけて書いてますね。
お恥ずかしいです。