緊急事態

時には、できるだけ早く全体のコードレビュープロセスを通過する必要がある緊急CLがあります。

緊急事態とは何ですか？

緊急事態のCLは、以下のような小さな変更です：メジャーローンチをロールバックせずに続行できるようにする、本番環境のユーザーに重大な影響を与えるバグを修正する、緊急の法的問題を処理する、重大なセキュリティホールを閉じるなどです。

緊急事態では、コードレビュー全体のスピードに本当に気を使います。ただし、レビュアーのスピードだけでなく、コードの正確性（緊急事態を解決するかどうか）についても、他の何よりも重視すべきです。また、（おそらく明らかですが）このようなレビューは、発生した場合には他のすべてのコードレビューよりも優先されるべきです。

ただし、緊急事態が解決された後は、緊急事態のCLを再度見直し、より詳細なレビューを行う必要があります。

緊急ではないものは何ですか？

明確に述べると、以下の場合は_緊急ではありません_：

• 来週ではなく今週にローンチしたいということ（ただし、パートナーとの合意など、実際の厳しい締切がある場合を除く）。
• 開発者が長い時間をかけて機能を開発し、CLを取得したいと思っている場合。
• レビューアーが現在夜間である別のタイムゾーンにいるか、オフサイトで不在である場合。
• 金曜日の終わりであり、開発者が週末に出発する前にこのCLを取得するのが良いと思われる場合。
• マネージャーが、ソフト（厳しいではない）締切のため、このレビューを完了し、CLを今日中にチェックインする必要があると言っている場合。
• テストの失敗やビルドの破損を引き起こしているCLをロールバックする場合。

などなど。

ハードデッドラインとは何ですか？

ハードデッドラインとは、もしもそれを逃すと何か災害的なことが起こるというものです。例えば：

• 特定の日までにCLを提出することは契約上の義務です。
• 特定の日までに製品をリリースしなければ、市場で完全に失敗します。
• 一部のハードウェアメーカーは年に一度しか新しいハードウェアを出荷しません。彼らにコードを提出する期限を逃すと、提出しようとしているコードの種類によっては、それが災害的な結果をもたらす可能性があります。

リリースを1週間遅らせることは災害的ではありません。重要な会議を逃すことは災害的かもしれませんが、しばしばそうではありません。

ほとんどの締め切りは、ハードデッドラインではなく、ソフトデッドラインです。それらは特定の時間までに機能が完了することを望んでいます。重要ですが、それを達成するためにコードの品質を犠牲にするべきではありません。

リリースサイクルが長い（数週間）場合、次のサイクルの前に機能を追加するためにコードレビューの品質を犠牲にすることは誘惑されるかもしれません。しかし、このパターンは、プロジェクトが圧倒的な技術的負債を蓄積する一般的な方法です。開発者がサイクルの終わり近くに「絶対に入れなければならない」という理由だけで表面的なレビューだけでCLを提出し続ける場合、チームはプロセスを変更して、大規模な機能変更がサイクルの初めに行われ、十分な時間があるようにすべきです。