- PR -

共通部分の多いWEBアプリケーション開発

«前のページへ 1|2
投稿者投稿内容
ちょま吉
大ベテラン
会議室デビュー日: 2004/08/04
投稿数: 112
投稿日時: 2005-10-14 23:17
私もuk様と同じ意見です。

それと、JSPまで共通化して、それを別プロジェクトにすると開発で困りませんか？
別プロジェクトですから、Eclipseのtomcatプラグインなどでtomcatを立ち上げてデバッグしたりできませんよね？

[ メッセージ編集済み 編集者: ちょま吉 編集日時 2005-10-14 23:25 ]
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2005-10-14 23:57
こんばんは。

引用:

ぬべたそさんの書き込み (2005-10-14 14:57) より:
１．
A社独自部分のプロジェクト、B社独自部分のプロジェクト、共通部分のプロジェクトの3プロジェクトを作り、管理する。

以上、宜しくお願い致します。

要件次第となるのですが、1.の方法を取ることはかなり危険な香りがします。
共通となる80%の部品は今後も共通であることが保障されているのでしょうか？
共通部分に位置づけた部品に対して、今後A社だけ(B社だけ)仕様変更が入る
可能性はありませんか？
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2005-10-15 00:06
引用:

ハツキタツミさんの書き込み (2005-10-14 16:38) より:
jarはクラスをパッケージングするだけですので、無理な気がします。


JSPやサーブレットを入れたいときはwarにしますね。
だから何だといわれても困るのですが…

第３案として、ログインユーザによって表示されるページを分けるのもアリだと
思います。当然ながら、A社・B社ともにそのことを同意の上でという前提条件が
必要ですが。

ina
ベテラン
会議室デビュー日: 2005/04/14
投稿数: 58
投稿日時: 2005-10-15 01:30
私もmasaさんと同意見です。
作り手側としてみたら確かに８０％は同じかもしれませんが、お金を払ってくれているユーザさんからみたら、そんなことは知ったことではありません。
なんで、（作り手側だけでみると現時点では無駄かもしれませんが）今後のことを考えて別プロジェクトとして割り切って取り組むことが基本だと思います。
＃でも、現時点ではほとんど同じなんですから、それぞれのチームで作業分担を決めて如何に楽をして物作りをしていくべきかといアプローチは大事だと思いますが．．．．．
なんで、今回の例では、パッケージ名しか違わないのが８０％って状態で納品するのがベストかな。
．．．．．
※Junitとかで、きちんとテストをしているのが大前提ですが．．．．．
Yugui
会議室デビュー日: 2005/02/16
投稿数: 1
投稿日時: 2005-10-15 16:14
masaさんの仰っているような変更可能性の問題がありますので、そのあたりをケースバイケースで考えて判断しますけれど、うちでしたらバージョン管理システム上で共通部分をベンダーブランチ化するなどで対処するかも知れません。
ぬべたそ
ベテラン
会議室デビュー日: 2003/12/18
投稿数: 72
投稿日時: 2005-11-01 07:55
業務に忙殺され、大変返信が遅くなって申し訳ありません。
みなさん、たくさんのご意見ありがとうございます。
色々な方法があるようで、まだ完全には決めかねています。

今は一応、A社用の物を基本とし、共通部分をB社用のプロジェクトへAntでコピーし、共通ではない部分はB社用に作り込むように考えています。
共通だと思われていた部分が共通ではなくなってしまった場合などは、リファクタリングによってパッケージ構成を変更するなどで対応しようと思います。（JUnitによる継続的な単体試験の実現が不可欠ですが）
View部分の共通化に関してはタグライブラリをということですが、使いこなしたことがありませんので、これから調査してみます。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-11-01 10:16
どもです。がると申します。
…なんていうか蝸牛よりもとろい反応で恐縮ですが。
共通系は割合に経験もあり、興味も多々ある内容なので
鈍重な反応を承知でちょいと書き込みを。

まず
引用:

現在、２社向けの業務系WEBアプリケーションを作成しているのですが、
A社向けとB社向けで80%以上が共通のものとなっています。

は、さらに以下のように切り分けると便利です。

1.たまたま共通になった感じであるもの
2.明らかにWebアプリに共通している、或いは共通しているように思われるもの

１番については「共通クラス化」する利点はなく、これらは
飽く迄「各クライアント固有のもの」にするほうが後々
楽です。
一方２番については「共通クラス化」したほうが圧倒的に
今後有利になります。

で。
引用:

共通だと思われていた部分が共通ではなくなってしまった場合などは、リファクタリングによってパッケージ構成を変更するなどで対応しようと思います。（JUnitによる継続的な単体試験の実現が不可欠ですが）

これについてはこんなものかと。

あと、共通クラスですが。なにも「あらゆるWebアプリで必ず」共通
である必要はないです。
使う側のイメージとしては「たまたま共通クラス群に便利なクラス
が落ちてたから使う」くらいのイメージでいくと楽かと思うです。
なので、作る側としては「重複したロジックは取り合えず共通
クラス群に突っ込んでみる」くらいの大雑把さで。
そういう細かい共通クラス群が集合していくと、それが財産に
なると思うので。

後は「変更ありうべし」くらいの柔軟さと曖昧さでやっていくと、
気軽に作れるし使えると思います ^^

以上、経験からの雑感でした。
何かの役に立てばよいのですが。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）