調査用のデバッグコードをリリースに混ぜない設計

調査用に仕込んだデバッグコードを、リリース前に手で消すのをやめました。台帳に登録し、同梱は build tag のオプトインにし、最後に成果物を grep して確かめる。台帳に記録されていた過去 3 件の事故は、どれも消し忘れではなくゲートの失敗でした。

この記事のテーマ

承認バーのバグを追うために、検出ロジックへ 37 行の記録用コードを仕込みました。原因が確定したら消す。似た症状が出たらまた書く。この往復をやめるための設計です。

台帳と期限は「消したか」を守りますが、「入ったまま出たときに何も起きないか」は守っていませんでした。記録されていた事故 3 件は全部ゲートの掛け方の失敗です。そこで build tag が同梱を、ランタイムゲートが収集を、成果物の grep が事実を、それぞれ別々に受け持つ形にしました。

途中で前提が 1 つ崩れています。日常で使っているバイナリはリリース版ではなく自分のビルドの成果物でした。確かめずに書いていた前提です。それが分かった時点で方針を反転しました。

記事全体の要約。台帳が「登録されているか」を、build tag が「同梱するか」を、成果物の grep が「本当に入っていないか」を、それぞれ別々に受け持ちます。