新卒社員が初めてやってみた！GitHub編QA（Trying GitHub for the First Time as a New Graduate!）

こちらは次のオンラインイベントのセッション中にうかがった質問への回答資料になります。
＜イベントページ＞
https://ibm-developer.connpass.com/event/368322/

Transcript

1. Q1、開発時、どれぐらいの規模の更新を行ったらプルリクエストを送るべきなのでしょうか？ あくまで一般論です。状況によっても違うので参考程度に。 ▪理想的なPRの特徴 小さく、意味のある単位であること ・1つの目的に集中している（例：バグ修正、機能追加、リファクタリングなど） ・レビューしやすく、テストしやすい ・コンテキストの把握が容易 ▪ PRの規模の目安 変更行数： 一般的には 200〜400行以内 が望ましいとされています（ただしプロジェクトやチームによる） ファイル数： 5〜10ファイル程度がレビューしやすい範囲。 時間的な目安： レビュアーが 30分以内でレビューできる 規模が理想。 セッション中にいただいた質問への回答１
2. Q２、レビュワーの負担を考えた時になるべくファイルチェンジを小さくしたいが フロントとバックエンドの差分が跨っている場合のPRをどこで切るかいつも迷います。 PR出す時の差分はどのように考慮してますか？ ※あくまで一般論です。状況によっても違うので参考程度に。 １、機能単位で切る おすすめ：1つの機能追加・修正に必要な最小限の変更を1つのPRにまとめる。 例：新しいAPIエンドポイントを追加し、それを使うUIコンポーネントを作る → 同じPRにまとめる。 理由：レビュアーが「このAPIはこのUIで使われている」と文脈を理解しやすく、動作確認もしやすい。 ２、インターフェースの変更が大きい場合は分割も検討 APIの設計変更が大きく、UI側の対応が複雑な場合は、以下のように段階的に分けるのもあり： PR①：バックエンドのAPI追加（既存のUIには影響なし） PR②：フロントエンドのUI変更（PR①がマージされた後） ３、Feature Flag や Mock を活用 バックエンドが未完成でも、フロント側を先に作りたい場合： モックAPIで開発 → フロントだけのPRを先に出す 実装完了後にバックエンドと統合するPRを出す ４、レビュアーとの事前共有も有効 「このPRはフロントとバックエンド両方にまたがってます」「レビュー負荷が高いかも」など、PRの説明文に明記 することで、レビュアーの心構えができます。 セッション中にいただいた質問への回答２