モジュールを再利用するのではなく、「クローン作成」するのはいつですか？
この質問では、議論を容易にするためのサンプルモジュールを示します。モジュールが計算エンジンであるとしましょう。現在、現在の対象者のためにその目的を果たしています。要件はクローン同じエンジンですが、まったく新しいオーディエンスのために微調整を使用することです。それを考えると、これらは設計ソリューションに影響を与える考慮事項/要因です。
- ユーザーは、現在のエンジンが要件の一部ではないため、変更なしのままであると期待しています（新しいエンジンは一部の新しいオーディエンス向けであり、現在のエンジンのユーザーには影響しません）。
- ＃1に加えて、変更が導入されていないため、現在のエンジンのコードベースの期待値は回帰テストなしです。
- ポイントを推進するためだけに、現在のエンジンをリファクタリングして、現在のエンジンと新しいエンジンの両方に柔軟に対応できるようにすることは、上記の2つのポイントを満たさないオプションではありません。
- 将来的には、エンジンごとに排他的な変更があると予想できます。変更は新しいエンジンにのみ適用されるため、電流に影響を与えることはありません。
- 厳しい締め切り。
しかし、私はまだ対立しています。
- それは本質的にコピー＆ペーストソリューションになります。
- 重複するコード。
- 両方に共通するはずのコード変更のメンテナンスの問題。
- 拡張機能の問題には対応していません。 3番目のエンジンなどがすべて可能である可能性があります。
上で強調したユーザーの期待を考えると、この状況では妥協は許容できますか？そしてフォローアップの質問ですが、競合する問題に対処すると同時にユーザーの要件を満たすソリューションに追加できるものはありますか？
コードの分岐を検討したいと思うようです。基本的には、2つのプロジェクトの開発とサポートのためにコードベースのクローンを作成し、必要に応じて変更を柔軟にマージできるようにします。したがって、バージョン管理システムに新しいブランチが作成され、ブランチまたはメインラインの元のバージョンのサポートを継続するかどうかを決定します。
最初のバージョンを段階的に廃止することを検討している場合は、サポートをブランチに投入し、2番目のバージョンをメインラインで続行することをお勧めします。ただし、どちらの場合も、メンテナンスによって古いバージョンと新しいバージョンの両方で役立つ変更が行われる可能性があるため、2つの個別のプロジェクトを編集しなくても変更を利用できるように、分岐/マージを管理する必要があります。
ここで答えを単純化しすぎたかもしれませんが、2つの製品間でコードベースの多くを共有する可能性があるときに、2つの別々の製品を維持することを選択した場合、深刻な管理オーバーヘッドとスケジューリングのボトルネックが発生することを指摘しておきます。
他の選択肢は、製品をより小さなモジュールに分割することかもしれません。変更されていないすべての共通コードが存在できる共通ベースレイヤー、およびベースの上位レイヤーとしての一意の依存製品のペア。これにも問題がある可能性がありますが、適切な自動ビルド/リリースプロセスでサポートされていれば、管理は比較的簡単です。
これは、時には対処して対応しなければならないビジネス上の問題の1つに思えます。たとえば、製薬業界に顧客がいて、生産ライン用にソフトウェアのバージョンを検証すると、大量の事務処理と再検証なしにバージョンを変更することはできません。これらのお客様向けにコードベースのカスタムブランチを維持しており、（ポリシーの問題として）存在する変更は、プロセスに関連すると見なされ、お客様の要求があった場合にのみ提供されるバグ修正のみであることを「保証」します。
これらの制約を考えると、最良のオプションはコードを2つのブランチにフォークすることだと思います。通常、これはバージョン管理システムで行います。not単純なファイルシステムのコピーです。バージョン管理システムでブランチを作成すると、共通の履歴が保持され、新しいブランチからレガシーブランチへのバグ修正の統合は、せいぜい自動で、最悪の場合はマシンの支援を受けて手動で実行できます。私はnotこれをコピーアンドペーストプログラミングのカテゴリに入れます。これは私が一般的に見下しているものです。
この開発パターンは実際には非常に一般的です。一部のソフトウェアのメジャーリリースを作成する場合、それをバージョン1.0と呼びます。基本的には、充電してバージョン2.0を開始するときに、変更しないでおく必要があります。リリースの頃に、メイントランクから1.0（または単にタグ/ラベル）と呼ばれるブランチを作成して、出荷されたものを明確にマークします。 2.0で作業しているとき、または人々がソフトウェアを使用しているときに、バグが発生し、修正が見つかります。
ここで、これらの修正を1.0ブランチとメイントランクの両方に本当に適用したいので、そうします。これにはいくつかのアプローチがあります。 1つは、1.0ブランチとメインブランチの両方の同じファイルに同じ編集を適用することです。これは最も簡単な方法ですが、エラーが発生しやすくなります。
もう1つは、1つのブランチに修正を適用してから、integrate変更されたファイルを1つのブランチから別のブランチに適用することです。大規模なプロジェクトでは、両方のブランチのファイルがリリース以降変更されておらず、同一である可能性があるため、これは多くの場合自動的に実行できます。バージョン管理システムは両方のブランチの履歴を知っているので、バージョン管理システムは一般に1.0以降のファイルで行われた新しい開発と混同されないため、1.0に修正を適用し、1.0からmainに統合することをお勧めします。修正を自動的に適用できます。バージョン制御システムでは、1.0以降のファイルの新しい開発である変更とバグ修正である変更の違いを区別できないため、逆の方向に進むことはお勧めしません。これにより、不適切なコードが1.0ブランチに導入される可能性があります。
メインブランチの1.0以降のファイルは、出荷されたものと大きく異なり、自動統合が不可能になる場合があります。この場合、修正を新しいコードに適用する必要がないか、単に注意して両方に手動で適用する必要があります。どのパスを選択する場合でも、チェックインする前に、変更内容を常に注意深く確認してください。