resources - 拡張/再利用のためのプロジェクトの再編成

Question

私が取り組んでいるプロジェクトの範囲は拡大中です。アプリケーションはかなり単純ですが、現在は非常に特定のニッチをターゲットにしています。近い将来、私はプロジェクトをフォークして新しい市場をターゲットにし、2 つのプロジェクトを並行して開発し続けるように依頼されました。

両方のプロジェクトは機能的に類似しているため、元のプロジェクトの根幹の多くを一般化する非常に強いインセンティブがあります。また、近い将来、より多くの市場をターゲットにしていると確信しています (市場は地理的なものです)。

問題は、プロジェクトの以前のメンテナーが、プロジェクトを元の市場に結び付ける多くの仮定を行ったことです。汎用コードを市場固有のコードから分離するには、かなりのリファクタリングが必要です。

物事をより複雑にするために、増え続ける市場のプロジェクトをどのように編成するかについて、いくつかの提案が飛び交っています。

1. 各市場は個別のプロジェクトであり、プロジェクト間の共通点は共有ライブラリに移動され、プロジェクトは個別に展開されます。
2. 既存のプロジェクトを拡張して複数の市場をターゲットにし、購入したライセンスに基づいて機能を制限します。
3. 親アプリケーションを作成し、個別に購入したプラグインとしてプロジェクトを再設計します

3 つの提案にはすべてメリットがあります。理想的には、コードを柔軟に構成して、わずかな調整でこれらのいずれかを実行できるようにしたいと考えています。提案 3 は、プラグイン アーキテクチャを構築する必要があるため、最も困難なようです。最初の 2 つの提案は、もう少しもっともらしいです。

これらの異なるアーキテクチャの長所と短所について利用できる適切なリソースはありますか?

プロジェクト間でコードを共有することと、コピーとフォークを比較することの長所と短所は何ですか?

Answer 1

フォークは通常、最初はより迅速に結果を得ることができますが、ほとんどの場合、メンテナンスであなたを悩ませます.1つのフォークからのバグ修正と機能拡張は、他のフォークで失われ、最終的にはフォーク全体を捨てていることに気づきます.そして、その機能を「最高の」フォークに再追加する必要があります。できれば避けてください。

先に進む: 3 つのオプションはすべて機能しますが、ビルドの複雑さ、メンテナンスのコスト、展開、通信のオーバーヘッド、および必要なリファクタリングの量に関してトレードオフがあります。

---

1. 各市場は個別のプロジェクトです

複数の市場向けに同時に開発する場合に適したソリューションです。

長所：

• これにより、市場 A の開発者は、B の進行中の作業に干渉することなく、A ビルドを中断できます。
• これにより、市場 A に加えられた変更が市場 B にバグを引き起こす可能性がはるかに低くなります。

短所：

• 時間をかけて共有コードを分離する必要があります
• 並列ビルドのセットアップに時間がかかる
• 共有コードへの変更は、両方のチームに影響するため、より多くのオーバーヘッドが発生するようになりました。

2. 既存のプロジェクトを拡張して複数の市場をターゲットにする

かなりの期間、問題なく動作させることができます。小規模なチームで、一度に 1 つの市場向けのリリースに取り組む場合は、それが最善の策かもしれません。

長所：

• (1) や (3) に進んだとしても、ライセンス作業はおそらく価値があります。
• 単一のコード ベースにより、すべての市場でのリファクタリングが可能になります。

短所：

• 市場 A 向けの作業を行っているだけでも、市場 B、C、D 向けのコードをビルドして出荷する必要があります。コード ベースが小さい場合は問題ありませんが、数千に達するとますます煩わしくなります。クラス
• 1 つの市場を変更すると、他の市場のコードが壊れるリスクがあります
• 1 つの市場を変更すると、他の市場を再テストする必要があります

3. 親アプリケーションを作成し、プロジェクトをプラグインとして再設計する

技術的に甘いと感じ、より多くのコードを共有できるようになるかもしれません。

長所：

• (1) のすべての利点に加えて、次の可能性があります。
  • 共有コードと市場固有のコードをより明確に分離
  • パブリック API に移行できる可能性があります。これにより、作業の一部を顧客にオフロードしたり、収益性の高いサービス プロジェクトを販売したりできます。

短所：

• (1) のすべての短所に加えて、さらにリファクタリングが必要です。

---

(2) は、ライセンスを除けば、現在自分がいる場所のようなものだと思います。しばらくそのままでいいと思いますが、(1) に向けて少し力を入れてください。たとえば、共有コードをすべて一緒にビルドしたとしても、別のプロジェクトに移動します。たとえば、市場からの依存関係を確認しようとします。コードから共有コードへはすべて一方向です。

(1)か(3)のどちらにたどり着くかは、種類によって異なります。ほとんどの場合、誰が「担当」するか、つまり共有コードか、それとも市場固有のコードかということになります。プラグインと、一部の共有コンポーネントを構成するコントローラー クラスとの間の境界線は、かなり曖昧な場合があります。私のアドバイスは、コードに必要なものを教えてもらうことです。

Answer 2

1) いいえ！同じコード ベースのさまざまなブランチを管理したくない... コードが一般的である可能性があるため、抜本的な変更を加えたいと思うでしょう。また、あるプロジェクトは「現時点では」他のプロジェクトほど重要ではありません。 、そして、他のブランチよりも速く成長するブランチを取得します.... スノーボールを挿入します。

2) これは多かれ少なかれ業界標準です。大きな構成ファイル、ライセンス/構成に基づいて物事を制限します。アプリが少し扱いに​​くくなる可能性がありますが、コードが相互に排他的なものについて不平を言っていて、すべての開発者が新しい機能とそれらがアプリケーション全体にどのように波及するかについて常にコミュニケーションを取っている限り、うまくいくはずです. それが懸念される場合、これはハッキングするのも最も簡単です.

3) これも機能します。C# を使用している場合、プラグインは比較的単純であり、依存関係の地獄について心配するだけで済みます。プラグインが循環的に相互依存する可能性がある場合 (つまり、a が必要 b が必要 c が a を必要とする)、これはすぐに爆発し、(非常に簡単に) #2 に戻ります。

あなたが持っている最高のリソースは、おそらく、さまざまなプロジェクトでの同僚の過去の経験と、ここやスラッシュドット、またはどこかでそれについてうんざりしている人々の経験です. 確かに最安。

コードを共有するメリット: 1 つの変更ですべてが変わります。統一されたデータ モデル。真実はただ一つ。（全員が同じページにいる方がはるかに簡単です）

コードを共有することの短所: 1 つの変更ですべてが変わります。注意してください。バグが 1 つでもあれば、すべてに影響します。

コピー/フォークの長所: 通常、特定の顧客向けに特定の機能を実装する方が迅速です。仮定 A は市場 B と C にのみ適用でき、D には適用できないことがわかっていると、ハッキングが速くなります。

コピー/フォークの短所: コードにまとまりがないため、コピーされたプロジェクトの 1 つ以上が最終的に失敗します。上記のように、スイープの変更にはもっと時間がかかります。

幸運を。

Answer 3

あなたは「コピーとフォーク」と言いましたが、おそらくこの「フォーク」をSVNのようなリビジョン管理システムのブランチとして管理することを考えていなかったと思います。このようにすることで、別の業界に対応するためにブランチをリファクタリングするときに、リビジョン管理システムの助けを借りて、それらの変更をメイン トランクにマージすることができます。

すべてのバリエーションが構成ファイル (または SQLITE 構成データベース) によって制御される単一のアプリに移行するという長期的な戦略に従っている場合は、このアプローチが役立ちます。両方の業界で一般化したと確信できるまで、何もマージする必要はありません。したがって、必要に応じて 2 つの独自のシステムを構築できます。しかし、すべてが 1 つのソース コード ツリー、レガシー業界のトランク、および新しい業界ごとの 1 つのブランチにあるため、追い詰められることはありません。

あなたの会社が本当に複数の業界を攻撃したいのであれば、構成データベース ソリューションがすべてのニーズを満たすとは思えません。なんらかの特別なコード モジュールが必要です。プラグイン アーキテクチャは、特に Python のようなスクリプト エンジンをアプリに埋め込む場合に役立つため、組み込むのに適しています。ただし、「数千のクラス」規模になると、プラグインがすべてのコード バリエーション要件を満たすことができるとは思いません。

新しい業界向けに今すぐ別のアプリを作成できるようにする実用的なアプローチを採用する必要がありますが、既存のアプリに改善を統合するのは比較的簡単です。数千のクラスといくつかの業界を持つ単一のトランクの涅槃に到達することは決してないかもしれませんが、少なくとも複雑さを飼いならし、業界のニーズに実際の相違がある場合にのみ、本当に重要なバリエーションに対処する必要があります.

私があなたの立場なら、「レポート」と見なされる可能性のあるアプリのすべての機能を調べて、それらを除外しようとするでしょう。