「該当ゼロ」と「読めていない」は見分けが付かない（検査を自分で緩めない作り）

671 本の設問を修正するにあたり、修正に先立って検査プログラムを書いた。感覚で直し始めないためだ。だが検査を書いた本人にはその検査の欠陥が見えない。複数の人が使ったら、作者が気づかなかった不備が次々と出てきた。表示する数字と判定に使う数字が違っていた。句読点を消して照合していたため、文をまたいで偶然つながった文字列を誤検知していた。修正を加えたら「該当ゼロ」が「該当 16」に増えた。

ここで重要な設計が『在庫ファイルは両方向でエラーにする』ということだ。既存の該当分を在庫に退避させるが、『新規に該当が出た場合』も『在庫から減った場合』も両方でエラーにして、在庫が単調に減る仕組みにしておく。足す機能を用意しないことも肝心だ。足せると、直すかわりに逃がす選択肢ができてしまうからだ。そしてシビアなのが『該当ゼロと読めていないは見分けが付かない』という点。検査が 0 件を返したのは「直ったこと」ではなく「読む対象を見つけられなかった」かもしれない。実際、YAML のキー名を読み違えて対象が 0 件になっていたことがあった。検査のコードそのものが正規表現の不具合で値を全部壊していたこともある。読めなかったら例外で止める必要がある。

要は『通ること』は見張っている証拠にならないということだ。壊して落ちるところまで見ないと、実は見落としていたことに気づかない。また「該当ゼロで安全」と文書に書いてあっても、その文書がコード実装と一致しているかは片方向チェックだけでは見逃す。「Cookie はログイン維持にのみ使う」と書いてあっても、実装にアクセス解析が入ると嘘になるが、条項を読むだけでは分からない。実装を確認して初めて矛盾が見える。品質チェックは一人で決めると必ず見落とし、別の人に使わせて初めて欠陥が顕在化する。