イテレーション
反復的かつインクリメンタルな方法で変更を提供するために、常に小さなマージリクエストを作成することを目指してください。
エンジニアはプロダクトマネジメントとのフィードバックサイクルにおいて重要な役割を担っています。エンジニアは追加の振る舞い/エッジケースが出荷にかける技術的な課題を理解しているため、MVC を設計する際に協力できます。計画・開発ライフサイクルのどの段階にいても、スコープを削減してより小さな変更を提供する機会が見えた場合は、できるだけ早くプロダクトマネジメントにフィードバックすることを常に試みてください。
マージリクエストを小さく保つ方法
最小限の動作する機能を導入する妨げとならないエッジケースを、フォローアップ Issue に切り出すことを検討してください。これにより、レビュー中にマージリクエストが膨らむことを防げます。また、フォローアップ Issue は、Issue が予想より複雑だった場合にチーム内で作業を分散するのにも役立ちます。
複雑なアプローチを必要とするリファクタリングは、実際の変更の前に別途導入するか、導入された変更による品質の低下がない場合はフォローアップとして導入できます。
Issue/マージリクエストの説明やコメントに「まずこれをして、それが動くことを確認して、これを洗練させる」と書かれている場合、それは作業が始まる前に分割できる可能性のサインでもあります。一般的に、エンジニアが「1コミット、1論理的変更」モデルに従っている場合、各コミットが個別のマージリクエストになり得ます。
水平スライシングと垂直スライシングのトレードオフ
開発者は小さなマージリクエストを作成する唯一の方法として水平スライシングを考えることがあります。変更をデータベース変更・バックエンド変更・フロントエンド変更（など）という水平なテックスタックベースの境界で分離します。ただし、このアプローチが常に効率的とは限らず、レビュアーが別々のレイヤーをレビューする際に全体像を把握できない場合に意味のあるフィードバックを提供するのが難しくなる可能性があり、完全なコンテキストを簡単に確認できない状態でコードをマージするリスクが増します。複数のスタックレイヤーに関わるマージリクエストの作業を開始する前に、チームとどのアプローチが最適かについて話し合うことを検討してください。
水平スライシング
- 各部分が大きく複雑な変更になる場合で、MVC をこれ以上分解できる明確な方法がない場合に有効です。
- スタックの各レイヤーが独立していて、レイヤーを個別に見るレビュアーがほとんどコンテキストを必要としない場合のマージリクエストに有効です。
- これを行う場合、全体的な変更をどこかに計画・説明してマージリクエストからリンクするか、マージリクエストの説明に明確に詳述する必要があります。
- スタックの各レイヤーが変更を完全に理解するために他に依存している場合は、可能であれば避けてください。たとえば、〜データベース（つまりデータベースマイグレーションが書かれる）への変更は、関連する〜バックエンド変更（新しいデータベースカラム/テーブルなどをクエリするコード）と密接に結合しているため、〜データベースレビュアーと〜バックエンドレビュアーの両方がそれらのコード変更を両方レビューする必要があるため、同じ MR に含めることが依然として望ましいです。
垂直スライシング
- これを行う場合、全体的なマージリクエストのサイズが許容できるレビュー範囲内に収まることを確認する必要があります。
- スタックの各レイヤーが互いにある程度依存しており、一緒に見ることでレビュアーの助けになる場合に有効です。
- 各部分が簡潔で互いに依存している場合に有効です。
- スタックの各レイヤーが複数のマージリクエストにまたがる複雑な変更を必要とする場合は避けてください。追跡が難しくなります。この場合、依然としてMVCをさらに分解しようとする必要がありますが、それが実行不可能な場合は水平スライシングの方が良いアプローチかもしれません。
