build-the-gate-before-the-content

全体にわたってルールを強制する必要のあるもの——スタイル制約、鮮度チェック、スキーマ、リンクバリデータ、予算など——をこれから作ろうとしている場合に当てはまる。自然な順序は、まずそのものを作り、チェック対象ができてからチェックを追加する、というものだ。

すでに存在するコードに追加するチェックには当てはまらない。それは別種の、より難しい仕事であり、その場合の答えは壁ではなくラチェット(一方向にしか戻せない歯止め)である。

1. チェックの対象となるコンテンツが何もない段階で、最初のコミットにチェックを追加する。これは自明に通る——それが重要な点であり、緑の状態からスタートする。
2. 何を実行すべきかを伝える失敗メッセージを用意する。出力が assert False だけのゲートは、深夜2時にそれに当たった次の担当者に削除される。
3. 100件目ではなく最初の違反で失敗するようにチェックを書く。ラチェットはレガシー向けであり、グリーンフィールドはゼロから始まる。
4. チェックが実際に発火したら、コンテンツを直す。代わりにチェックの方を変更するたびに、どのケースがそれを強いたのかをコミットメッセージに記す。

コンテンツより前に書かれたゲートは、まだ存在しないコンテンツについての想定を組み込んでおり、その想定のいくつかは後で間違っていたと判明する。初期のうちに1、2回は縮小することを見込んでおくこと。

その縮小こそが危険な瞬間である。縮小のたびにルールは弱くなり、誰にも気づかれずに3回縮小されたルールは、もともと書かれた対象のケースをもはやカバーしていないルールになる。すべての縮小を、それを引き起こした失敗例とともに固定すること。