@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
Javaのフレームワーク設計
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-10-26 02:19
いつもお世話になっております。
とある基幹システムに導入する新規Javaのフレームワークや共通機能の設計を 担当しております。 別システムとのコネクタや、例外処理設計などなど・・。 ただ経験不足からかノウハウが無く、うまくいっておりません。 昔JSPやServletでWebシステムの画面周りのPGは経験があるのですが、 フレームワークや共通機能となると、また違う経験や発想が必要な気がしています。 オブジェクト指向、デザインパターン、Jakarta プロダクト、J2EE、DIなど・・ 色々なキーワードがあるのですが、「フレームワーク設計」やアプリケーションアーキテクチャの設計となると、こういった技術的要素の学習や理解がまず大前提となるのでしょうか?。 運用担当や開発者に優しい構成に・・というちょっと違う視点のアドバイスも 受けたことがありますが・・。 初歩的な質問で申し訳ありません。 皆様のご経験など教えて頂けますと助かります。 よろしくお願いします。 | ||||||||||||
|
投稿日時: 2007-10-26 02:39
# 個人でやっているのであればともかくですが
会社として受けた仕事なのですよね? ご自身にノウハウや経験がなくても、このような仕事を受けたのであれば それらを持っている方は必ずいるはずです。 まずは掲示板などに相談する前に、周りの方に相談すべきだと思いますよ。 | ||||||||||||
|
投稿日時: 2007-10-26 08:03
列挙されたキーワードはJavaの開発者としては持っているべき基本的な知識なので、 学習されるべきだと思います。 ただこうした知識がなくても、フレームワークやアーキテクチャーは作れますが生産性や品質は低くならざるを得ないかと思います。 | ||||||||||||
|
投稿日時: 2007-10-26 08:10
まず全体にどのような開発をさせたいか?
という視点で、イメージを膨らませましょう。 また方式設計を行うアーキテクトの権力は絶大なので、 設計に失敗するとものすごい工数が失われてしまいます。 できないのであればできないと言ってしまうのも手かと思います。 | ||||||||||||
|
投稿日時: 2007-10-26 09:59
ソフトウェアというものは目的を達成するための手段であるわけです。
フレームワークなどのミドルウェアの目的というものをよく考えてみてください。 コンセプトは明確に持つべきです。 何を可能とするためのフレームワークなのか、何に特化して何を切り捨てるのか。 「生産性向上」という目的では曖昧すぎる。 どういう方向性でそれを成し遂げようとするのか、そこが重要です。 もちろん、まったく新規にアイデアを出せというのま無茶というものです。 既存のフレームワークがどういったコンセプトで設計され、 その結果どのようなメリットが生まれたか、また、今なお残るデメリットは 何であるかを調べるところから「あるべき形」が見えてくるのではないでしょうか。 | ||||||||||||
|
投稿日時: 2007-10-26 10:51
簡単にできるかは別として、簡単に言うと、
「オープンソースのフレームワークのコードを読んで勉強するべし」 くらいですかね・・・。 自分がプロジェクト用のフレームワークを設計するときは、 アプリ開発者がどういう風にコードを書けるようにするべきかを考えます。 そのアプリのコードを擬似コードとして表現し、 その擬似コードが動作するように設計しています。 ・最低限のコードで仕様が満たせること ・イレギュラーケースに柔軟に対応できること ・テストしやすいこと ・疎結合であること この辺を特に意識します。 こういった設計を何度か繰り返すと、 それなりに洗練されてくるでしょう。 | ||||||||||||
|
投稿日時: 2007-10-26 12:50
たとえばですが、機能が乏しい薄いラッパー(wrapper)のようなフレームワークは、ややこしいコーディング規約が、さらに勢力を広げてクラスやメソッドまで侵食したようなもので、とても使いにくくなります。
存在や、なにができてなにができないのかの概要ぐらいは知っておくべきでしょうけど、たくさんのものを細かなところまで理解するのは、さすがに難しいのではないでしょうか。
どう「優しい」と良いのでしょう?見た目の優しさの裏返しは冗長さにつながったりしますので、コードを書く人のアドバイスでない限り、のらりくらりと受け流したほうがよい場合もあります。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} |
1