【要約】「発動しました」を信じるな ― 検知器の前提条件を独立に再計算して二重バグを見つけた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、自動売買システムの検知器において、表示される前提条件と実際のデータが矛盾する問題に直面した。検知器が「発動」と表示しながら、実際には条件を満たしていない事態が発生した。
- ・表示用の判定ロジックと、内部フラグ用の判定ロジックが別々に管理されていた。
- ・機能追加時に片方のロジックのみが更新され、二重管理による不整合が生じた。
- ・ユニットテストは内部関数のみを対象とし、本番の表示出力の正しさを保証できていなかった。
// Approach
開発者は、検知器の出力を鵜呑みにせず、独立したレイヤで真の状態を検証する「pPRP」を導入した。検知器のコードに依存せず、生のデータから前提条件を再計算する手法である。
- ・検知器のコードを一切 import せず、生の価格データから前提条件を再計算する。
- ・判定ロジックを仕様書レベルで独立して記述し、検知器のバグを再生産しない。
- ・検知器の表示結果と、独立計算した真の値を突き合わせ、不一致があれば警告を出す。
- ・False Positive と False Negative の両方向を監視対象とする。
// Result
検証層の導入により、開発者は検知器に潜んでいた二重のバグを確実に特定できた。検知器の内部テストだけでは見えなかった、表示層の不整合が浮き彫りになった。
- ・「表示は発動だが前提不成立」という False Positive を1件検出した。
- ・「表示は非発動だが前提成立」という False Negative を1件検出した。
- ・検知漏れによる判断精度の劣化や、機会損失を防ぐ仕組みを構築した。
Senior Engineer Insight
> 「検知器は自分自身のバグを検知できない」という設計上の限界を突いた、極めて実戦的なアプローチだ。DRY原則を優先してロジックを共通化しすぎると、今回のような不整合を招く。検証層を「検知器のコードをimportしない」という制約で小さく保つ判断は、運用コストと信頼性のバランスにおいて極めて正しい。監視系やフィーチャストアなど、データの整合性がクリティカルな領域では、この「独立した検証レイヤ」の設計思想は必須と言える。