私は、多くのレガシーCOBOLコードがあり、分岐と分岐を可能な限り最小限に抑えるための方法論が採用されている小さなショップで働いています。
特定のリリースには、次の3つのレベルがあります。
- CORE-最下層、このコードはすべてのリリースに共通です
- GROUP-複数の顧客に共通のオプションのコード。
- CUSTOMER-単一の顧客に固有のオプションのコード。
プログラムが必要な場合、最初にCUSTOMERで検索され、次にGROUPで検索され、最後にCOREで検索されます。特定のアプリケーションは、この順序ですべてが検索される多くのプログラムを呼び出します（WindowsではexeファイルとPATHを考えてください）。
また、このレガシーコードと相互作用するJavaプログラムもあります。コアグループと顧客のルックアップメカニズムは、Javaに簡単に対応できないため、顧客ごとにCVSブランチで成長する傾向があり、メンテナンスが多すぎます。Java部分とバックエンド部分は並行して開発される傾向があります。
私は、2つの世界を出会いさせる方法を見つけるように割り当てられました。
基本的に、リリースごとにソースを含む単一のコードベースを持つことができるJava環境が必要です。この環境では、グループと顧客を簡単に選択して、その顧客に合わせてアプリケーションを操作し、別のコードセットに簡単に切り替えることができます。そしてその顧客。
コア、顧客、グループごとにEclipseプロジェクトを使用するシナリオを考えていたので、プロジェクトセットを使用して、特定のシナリオに必要なものを選択しました。私が頭を悩ませることができない問題は、どのグループと顧客が選択されたかに関係なく機能するCOREプロジェクトでどのように堅牢なコードを作成するかということです。渡されたClassオブジェクトのどのサブクラスを、すべての新しいものではなく呼び出すかを知っているファクトリクラス？
他の人も同様のコードベース管理の問題を抱えていたに違いありません。共有する経験を持っている人はいますか？
編集：上記のこの問題の結論は、CVSを、多くのブランチを同時に処理し、履歴を保持しながら1つのコンポーネントから別のコンポーネントにソースを移行するのに適したソースコード管理システムに置き換える必要があるということです。slf4jとlogbackによる最近の移行に触発されて、ブランチを非常にうまく処理するgitを現在検討しています。SubversionとMercurialも検討しましたが、単一の場所、複数のブランチを持つプロジェクトにはgitの方が適しているようです。私は別の質問でPERFORCEについて質問しましたが、私の個人的な傾向は、これと同じくらい重要な何かのためのオープンソースソリューションに向かっています。
編集：もう少し熟考した後、私たちの実際の問題点は、CVSでブランチを使用することであり、すべてのファイルをブランチする場合、CVSでのブランチが最も扱いやすいことがわかりました！改訂された結論は、それぞれが上記のレベルの1つに対応するJavaプロジェクトのフォレストに切り替え、Eclipseビルドパスを使用してそれらを結び付け、各CUSTOMERバージョンが適切なグループを取り込むことにより、CVSのみでこれを行うことができるというものです。とCOREプロジェクト。それでも、より優れたバージョン管理システムに切り替えたいと考えていますが、これは非常に重要な決定であるため、可能な限り遅らせたいと考えています。
編集：GoogleGuice2.0を使用したCORE-GROUP-CUSTOMERコンセプトの概念実証実装ができました。@ImplementedByタグはまさに必要なものです。他のみんなは何をしているのだろうか？いたるところにifを使用していますか？
編集：今、私はWebアプリケーションにもこの機能が必要です。JSR-330が設置されるまではGuiceでした。バージョニングの経験がある人はいますか？
編集：JSR-330 / 299は、JBoss Seamに基づくJEE6リファレンス実装Weldで配置され、Weldで概念実証を再実装し、Beanで...とともに@Alternativeを使用すると確認できます。 xml私たちは私たちが望む振る舞いを得ることができます。つまり、CORE jarのビットを少し変更することなく、COREの特定の機能に新しい実装を提供します。サーブレット3.0仕様を最初に読んだところ、 （コードではなく） Webアプリケーションリソースに対して同じ機能をサポートしている可能性があることがわかりました。次に、実際のアプリケーションで初期テストを行います。