緊急事態

緊急の CL というものがときどきあります。緊急の CL は可能な限りすみやかにコードレビューの全プロセスを通過させる必要があります。

緊急事態とは何か？

緊急の CL は小さな変更になるでしょう。たとえば、ローンチ済みの主要機能をロールバックするのではなく継続するための変更、本番環境のユーザーに重大な影響を与えるバグの修正、切迫した法的問題の対応、深刻なセキュリティホールの修正等です。

緊急事態で私達が尽力するのはレビューの応答の速さだけでなくコードレビューのプロセス全体の速度です。この場合に限り、レビュアーはすみやかにレビューすることとコードの正確さ (緊急事態を本当に解決しているだろうか？) に何よりも集中してください。また、(当然かもしれませんが) このレビュー依頼が来たら他のレビューよりも最優先で取り組んでください。

しかしながら、緊急事態が解決したあとは緊急の CL をもう一度見て、全体的なレビューを再度行ってください。

緊急事態でないものは何か？

はっきりさせるために、緊急事態でないものを以下に挙げます。

• ローンチを来週から今週に早めたい (例外としてパートナーの同意のようなハードな納期が実際にある場合は別です)
• 開発者がある機能について非常に長期間にわたって作業しているため、CL をそろそろいい加減取り込んでほしい。
• レビュアーが皆、他のタイムゾーンにいて今は夜だったり現場にいなかったりする。
• 今が金曜日の終業間際で、開発者が週末に去る前にこの CL を取り込んでもらえると素敵だ
• マネージャーが (ハードでなく) ソフトな納期のためにこのレビューを今日中に完了させて CL を取り入れなければならないと言っている
• テストの失敗やビルドの破壊を引き起こしている CL のロールバック

ハードな納期とは何か？

ハードな納期とはそれを逃すと大きな損害が発生する納期のことです。たとえば以下のようなものです。

• 契約上の義務からある期日までに CL を提出する必要がある。
• ある期日までにリリースしなければそのプロダクトが市場で完全に乗り遅れてしまう。
• あるハードウェアメーカーは新しいハードウェアを年に一度しかリリースしない。納期までにコードを提出しないと、リリースしようとしているコードの種類によっては大きな損害が発生する。

リリースが一週間遅れても大きな損害にはなりません。重要なカンファレンスを逃すと損害が大きくなるかもしれませんが、とはいえ頻繁に起こるケースではありません。

ほとんどの納期はソフトな納期であって、ハードな納期ではありません。ある機能が期日までに実装されてほしいという願望を述べているだけです。それは重要ではありますが、そのためにコードの健康状態を犠牲にすべきではありません。

リリースサイクルが数週間にわたる長い期間だったりすると、次のサイクルに入る前にコードレビューの品質を犠牲にしてまである機能を取り入れてしまいたいという誘惑があることがあります。けれども、このパターンが繰り返されると、プロジェクト技術的負債があるとき噴出することになります。開発者が CL をリリースサイクルの終盤に提出し、表面をなぞるだけのレビューで CL を「取り入れなければならない」といったことが習慣的に行われているなら、チームは開発プロセスを見直すべきです。大きな機能変更はリリースサイクルの初期に提出し、きちんとレビューするための時間を十分に確保できるようにしてください。