
#19 printfデバッグしたら"負け"——デバッグは設計で決まる
printfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ(デバッガビリティ)はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。
printfを仕込んで消すその場しのぎの確認ではなく、まず再現テストを書く。バグが出るのはアルゴリズムとドメイン知識が混ざった「もやっとした場所」だから、ソート関数と大小比較のように分離してプロパティベーステストで固める。
iOSアプリなど状態を持つクライアントサイドでは、状態遷移をログに残す設計にしておけばAppleの審査で指摘された課金バグも一瞬で特定できる——という実話も登場します。
さらにRedux/TCAのシングルデータストアが本当にテストしやすいのかへの異論、「仮説を立てる」より「切り分け」で二分探索的に原因を追い詰める考え方まで、デバッグ観がひっくり返る回です。
▼この回で話していること
・printfデバッグ・ステップ実行が「負け」な理由と、ログ出力(debug/traceレベル)との違い
・デバッグの代わりに再現テストを書くという考え方
・バグはテスト不足のサイン——デバッガビリティの高い設計とは
・アルゴリズムとドメイン知識の分離(ソート関数と比較関数の例)とプロパティベーステスト…
The skinny
The skinny isn't ready yet — notes appear once the transcript is processed.