類似しているが独立した機能を処理する正しい方法は何ですか？
機能リクエストが届き、作業を開始するとします。これをfeature-1と呼びます。これは、アプリケーションにいくつかの新しいロジックを導入します。これをlogic-Aおよびlogic-Bと呼びます。プログラマーはリリースブランチから分岐し、機能の作業を開始します。
その後すぐに、feature-2と呼ばれる別の機能リクエストを受け取ります。 logic-Aおよびlogic-Cをアプリケーションに実装します。この機能によって実装されるlogic A）は、実装されたものと同じlogic-Aです。 infeature-1。
また、与えられたlogic-B、logic-Aは、与えられたものとは少し異なる方法で実装される可能性があるとしましょうlogic-C、およびlogic-Bとlogic-C（たとえば、機能が1つしかない場合、コードは両方の場合よりも柔軟性が低くなります）。
この状況はどのように処理する必要がありますか？
具体的な例（私の言い回しの混乱を助けるため）
- feature-1はprogrammers.stackexchange.comからのフィードです。
- feature-2はgameing.stackexchange.comからのフィードです。
- logic-Aは、フィードの実装であり（アプリケーションに現在フィードがないと仮定）、コンテンツにもリンクして関連情報を提供します。
- logic-Bは、フィードのソースがprogrammers.stackexchange.comからのものであることです。
- 関連するプログラミング言語が表示されることをlogic-Aに追加します。
- logic-Cは、フィードのソースがgameing.stackexchange.comからのものであることです。
- 関連するゲームの名前とボックスアートが表示されることをlogic-Aに追加します。
状況は常に完全に予測できるとは限りません。変化にすばやく適応できることが、このアジャイルなもののすべてです。あなたはできるだけ早く顧客のために価値を解放したいと思っていますが、それはあなたがほとんどすぐに再設計を必要とすることがわかっているコードを作成することによってあなた自身を隅に追いやる必要があるという意味ではありません。
私があなたの例でfeature-2開発者だった場合、割り当てを受け取り、他の誰かがすでに同様のことに取り組んでいることを知ったとき、私は次のようになります。
- feature-1開発者と話をして、共通のロジックを一緒に作業できるブランチについて合意します。これは、彼がすでに作成したブランチであるか、共通ロジック専用の別のブランチである可能性があります。
- 両方の機能に対応するために、共通ロジックの現在の設計にどのような変更を加える必要があるかを判断します。
- feature-1のリリース日にこれらの変更が与える影響を判断します。
- feature-1への影響が最小限である場合は、共有ブランチで共通のロジックを変更して先に進みます。
- feature-1に重大な影響がある場合は、別のブランチで共通のロジックを変更し、feature-1の終了後にマージします。他の開発者はこれを手伝うことができます。
- feature-1に重大な影響がある場合の別のオプションは、影響の少ない一時的な変更を今すぐ行って、影響の大きい変更を将来的に簡単にできる場合があることです。オールオアナッシングの間違いをしないでください。たとえば、プログラミング言語のような「余分な」データの表示を独自の関数に分離すると、後でそれを構成するのが簡単になります。
Feature1で多くの作業が行われる前にfeature2が到着したと思います。それ以外の場合は、最初にfeature1を終了する必要があります。ただし、選択する余裕がある場合は...プロジェクトに追加する価値に基づいてfeature1とfeature2に優先順位を付けます。最初に追加する機能に役立つ方法でlogicAを追加します。少なくとも、別の機能にlogicAを使用することに注意することは問題ありませんが、気を悪くしないでください。最初の機能を終了すると、logicAは可能な限り最高の価値を獲得します（最も価値のある機能を優先したため）。必要に応じてlogicAをリファクタリングして、他の機能を実装します。これにより、最も早く最大の価値が得られます。
最初の機能をコーディングした後、logicAのリファクタリングのコストが高すぎるかどうかを判断し、より価値が高くならない限り2番目の機能を実行しない機会が得られます。あなたはlogicAについてもっと知っています。たぶん、logicAを再利用できないというあなたの恐れは根拠がありません。また、logicAの実装経験もあります。したがって、logicAをリファクタリングまたは完全に再設計する必要がある場合は、ユースケースの実際の知識がないという観点から考えられる用途向けにlogicAを設計しようとするのではなく、知識の観点から行うことができます。
これは、gitの質問というよりもプロジェクト管理の質問です。
2 [〜＃〜]投資[〜＃〜] ストーリーを作成するのが最善です：
- フィードの実装に必要な汎用ロジックを実装します（logic-A）。そして、最も価値のあるフィードのロジックを実装します。したがって、ロジックBまたはCのいずれか
- ストーリー1の汎用ロジックを使用して実装されていないフィードを実装します。したがって、ロジックBまたはCのいずれかです。
次に、ストーリー2を計画する前に、スプリント/リリースでストーリー1を計画します。ストーリー2の作業は、ストーリー1が終了するまで開始できないため、ストーリー1が配信された後のリリースで計画する必要があります。ストーリー1はストーリー2の依存関係です。したがって、ストーリー1が何らかの理由で終了しない場合、ストーリー2はブロックされます。
したがって、ストーリー1がリリース1にならず、リリース2に移動した場合、ストーリー2をリリース3に移動する必要があります。これは、ストーリー1が実際に終了するまで続きます。
同じストーリーに共通のロジックを実装する必要がある理由。これは、実装時に、共通ロジックの開発中に予測していなかったエッジケースで実行されるためです。
実装せずに最初に共通ロジックを構築するだけでは、付加価値がないため、 [〜＃〜] Investment [〜＃〜] ではありません。このように作業すると、 オーバーエンジニアリング および機能の追加 必要ない のリスクが高まります。
両方の機能の開発中に依存関係が発見された場合。ベストプラクティスは、これらの機能の1つを障害物に置き、その機能の開発を一時停止することです。