View on GitHub

google-engineering-practices

Google's Engineering Practices Documentation Japanese Translation

緊急事態

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

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

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

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

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

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

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

などなど。

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

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

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

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

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