#19 printfデバッグしたら"負け"——デバッグは設計で決まる

printfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ（デバッガビリティ）はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。

printfを仕込んで消すその場しのぎの確認ではなく、まず再現テストを書く。バグが出るのはアルゴリズムとドメイン知識が混ざった「もやっとした場所」だから、ソート関数と大小比較のように分離してプロパティベーステストで固める。

iOSアプリなど状態を持つクライアントサイドでは、状態遷移をログに残す設計にしておけばAppleの審査で指摘された課金バグも一瞬で特定できる——という実話も登場します。

さらにRedux/TCAのシングルデータストアが本当にテストしやすいのかへの異論、「仮説を立てる」より「切り分け」で二分探索的に原因を追い詰める考え方まで、デバッグ観がひっくり返る回です。

▼この回で話していること

・printfデバッグ・ステップ実行が「負け」な理由と、ログ出力（debug/traceレベル）との違い

・デバッグの代わりに再現テストを書くという考え方

・バグはテスト不足のサイン——デバッガビリティの高い設計とは

・アルゴリズムとドメイン知識の分離（ソート関数と比較関数の例）とプロパティベーステスト

・ステップ実行が正当化される例外：パフォーマンス優先のホットスポット

・クライアントサイド（iOS）のデバッグ：状態機械（ステートマシン）と状態遷移ログ

・Flux/Redux/TCAのシングルデータストアはテストしやすいのか？——インターフェース分離原則から考える

・「仮説を立てる」より「切り分け」——二分探索で原因を特定するデバッグ手順

▼こんな人におすすめ

・printfデバッグから抜け出したい、デバッグのやり方を体系的に知りたいエンジニア

・テストが書きにくいコードに悩んでいて、テストしやすい設計を学びたい人

・Redux/TCAなどの状態管理アーキテクチャの採用を検討している人

▼関連リンク

・Redux 公式サイト: https://redux.js.org/

・The Composable Architecture (TCA): https://github.com/pointfreeco/swift-composable-architecture

・StoreKit（Apple Developer Documentation）: https://developer.apple.com/documentation/storekit

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想はハッシュタグ #くわラジ でお寄せください。

─────────────

YouTube: https://youtu.be/D4bOru9qBEY

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji