原因候補が広い時は、最初から順に読むより中間地点で確認します。
データの流れを半分にする
入力 -> 変換A -> 変換B -> API -> DB
まずAPI直前の値を確認します。
- すでに間違っている: 入力〜変換Bを調べる
- 正しい: API〜DBを調べる
次も残った範囲の中間を確認します。
コミットにも使える
以前は動いていたコミットと、現在の壊れたコミットが分かるなら、git bisectで原因を含む変更を絞れます。
git bisect start
git bisect bad
git bisect good <動いていたコミット>
表示されたコミットをテストし、git bisect goodかgit bisect badを繰り返します。終了後は次で戻します。
git bisect reset
向いている問題
- 途中までは値が正しい
- 変更履歴のどこかで壊れた
- 多数の設定のうち一部が原因
複数原因が同時にある場合は判断が難しくなるため、再現条件を固定してから使います。
次に読む記事
← 一覧に戻るPR
PR