コードレビューを優先的に取り組む

• レビューを優先して取り組む理由
  • なぜ自分のタスクより他人のPRのレビューを優先するのか
  • PRは、なるべく早くマージすることが好ましいと思う。
    • 時間が経てば立つほど、マージ先ブランチとの差分が開く。コンフリクトが起きたり、そもそも変更が必要なくなったり、新たな考慮事項が増えたり
      • 都度都度対応するコストや、タスクの完遂スピードが落ちる。
    • Authorが完了していないタスクを抱える認知的コスト
      • マルチタスク状態。大多数の人間はマルチタスク状態になるとパフォーマンスが落ちる。
  • PRを早くマージするためには
    • Author:
      • PRの目的、PRでの変更点とそれを実現する手段をReviewerが最も簡単に認知できるようなPRを作る
        • Descriptionやセルフレビューコメントを充実させる。
        • 口頭でのコミュニケーションを活用する。
      • PRでの変更行数を最小にする。
        • 複数PRに分けて実装する。
    • Reviewer:
      • 早く見る！！
      • 同期的なコミュニケーションを活用する。
  • 早く見る！！
    • どのくらい早く見たらいいの？ (現状の開発体制、事業フェースにおけるhagiの主観)
      • 前提、急ぎの場合はAuthor主体で期日をコミュニケーションするのが好ましそう。
      • 基本的には、自分のタスクの最重要事項として考える。
        • 実装 ~80% レビュー中 ~90% マージ時点 ~100% →リリース、 価値提供
        • ↑の構図を考えると、自身の80%の実装を優先するよりも90%の段階にある実装をレビューして早くリリースしたほうが、早く価値提供に直結する。
      • 自身の集中力を打ち切るのは全体の生産性が下がることを考えると、今の実装のキリが良いところまでやることもある。
      • (予定や、どうしても急ぎの開発がある場合は、そちらを優先することもある。)