緊急事態

すべてのコードレビューをできるだけ速く行わなければならない、緊急事態の CL というものが存在します。

緊急事態とはどのような時か？

緊急事態の CL とは、本番環境上でユーザーに非常に大きな影響を与えるバグを修正したり、差し迫った法律上の問題を処理したり、主要なセキュリティホールを修正したりするなど、ロールバックではなく、連続して適用する必要がある変更小さな変更のことです。

緊急事態では、私たちはレスポンスのスピードだけではなく、コードレビュープロセス全体のスピードについて極めて慎重になります。レビュアは、レビューの速さと、他の何よりもコードの正しさ (この CL が実際に緊急事態を解決するものとなっているのか？) について注意深く確認しなければなりません。また、(おそらく自明ですが) 緊急事態のレビューは、他のすべてのコードレビューに優先して、CL が送られてきたタイミングで行わなければなりません。

しかし、緊急事態が解消された後には、緊急事態の CL 全体をもう一度見直し、より完全なレビューを行わなければなりません。

緊急事態でないのはどのような時か？

緊急事態について明確にするために、以下に緊急事態ではないような場合を挙げます。

• 来週ではなく今週中に、新機能を立ち上げたいと望んでいる場合 (パートナー契約などの具体的なハード・デッドラインが存在する場合を除く)。
• 開発者が1つの機能に非常に長い時間、取り掛かり続けており、CL を取り込んでほしいと心から願っている場合。
• 現在、レビュアの全員が深夜や勤務時間外である別のタイムゾーンにいる場合。
• 金曜日の1日の終りで、週末に開発者が離れる前にぜひとも取り込んでおきたい CL がある場合。
• ソフト・デッドライン (ハード・デッドラインではない) が存在するため、マネージャが今日中にこのレビューを完了させて CL をチェックインする必要がある、と言っている場合。
• テストの失敗やビルドの破壊を起こした CL をロールバックする場合。

などなど。

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

ハードデッドラインとは、もし守れなかったときに何らかの大きな損害が発生すると考えられるような締め切りのことです。たとえば、次のようなものがあります。

• あなたの CL を特定の期日までに送信することが契約上の義務である場合。
• 特定の期日までにリリースしなければ、あなたのプロダクトが市場で完全に失敗することになる場合。
• ハードウェア製造者は1年に1回しか新しいハードウェアと製造できない場合があります。あなたが出荷しようとしているコードの種類によっては、もし製造者にコードを送信できなかったために締め切りが守れないと、大きな損害に繋がる可能性がある場合。

リリースが1週間遅れることは大きな損害とはなりません。重要なカンファレンスに出席できないことは大きな損害となることもあるかもしれませんが、大抵は違います。

ほとんどの締め切りはソフト・デッドラインであり、ハード・デッドラインではありません。ソフト・デッドラインは、特定の期日までにある機能が完成してほしいという要望を表現したものです。もちろんソフト・デッドラインも重要ですが、そのためにコードの健康状態を犠牲にしてはなりません。

長期間のリリースサイクル (5、6週間くらい) がある場合、ある機能を次のサイクル前にリリースするために、コードレビューの質を犠牲にしようとすることも可能かもしれません。しかし、よくあるパターンは、このようなことを繰り返すことで、プロジェクトが数え切れないほどの技術的負債を積み上げてしまうことになるというパターンです。もし開発者がサイクルの終わりに CL を提出し、表面的なレビューだけで「CL を取り込まなければならない」ということが日常化しているのであれば、チームは開発プロセスを見直すことで、大きな機能変更がサイクルの早い時期に起こるように調整し、よいレビューができるだけの十分な時間を確保するように軌道修正しなければなりません。