そのプログラムの仕事は単純で、すべてのスタイルファイルを調べ、デザイントークンを通さずに16進数のカラーコードが直書きされている箇所を見つけるものでした。

書いた日に一度走らせて、グリーン。その後も毎日走らせて、毎日グリーンでした。

2週間後、ファイルをなんとなく眺めていた人が、明らかな直書きのカラーコードを見つけました。本来なら引っかかるはずのものです。

さかのぼって調べると

マッチに使う正規表現の文字クラスが1つ足りず、スキャン対象を解決した結果が空のリストになっていました。

毎日きちんと0個のファイルを調べて、「問題なし」と報告していたわけです。

2週間そのものは大した損失ではありません。困ったのは、その間この件は誰かが見ていると思っていたので、自分の目では見なくなっていたことです。

正規表現を直しても、直るのは今回だけ

次に別のチェッカーを書けば、同じことがまた起きます。そこで、チェッカーには必ず、それを失敗させる入力を添えるという決まりを作りました。

仕組みは --selftest というオプションです。わざと壊したダミーデータを流し込み、チェッカーがエラーを出さなければ、--selftest 自身が終了コード1で終わります。

これでグリーンの意味が変わりました。以前は「問題が見えなかった」。いまは「見た。見えることも確かめてある」です。

プログラムだけの話でもない

デザインガイドラインも同じです。誤用例が載っていなければ、手元の1枚が違反かどうかは誰にも判断できません。それでは提案の束と変わりません。

引き継ぎ資料もそうです。誰も一度もゼロからなぞったことがなければ、どれだけ丁寧に書いてあっても、読んだ感触は回顧録に近くなります。

いま私たちは、「チェックを受け持つ」ものを渡されたら、まずひとつ聞くことにしています。これが「だめ」と言う例を1つ挙げられますか。