まわりのサーバーサイドエンジニアでデバッガーを使っている人は思ったより少ない
感覚で言うと半数ぐらい
プリントデバッグとE2Eテストでなんとかなるらしくそれは私も同意する
これは作っている対象がステートレスなウェブアプリケーションだというのが影響していると思う
モバイルアプリやフロントエンドのSPA開発はステートフルなので内部状態を確認しながら開発したいタイミングが結構ある
私もXcodeとgcc のデバッガーで便利さを覚えた
ただ最近はステートレスなコンポーネントを構築するスタイルに移ってきているのでなんとかなるのかもしれない
コミュニティによって差もあり、言語処理系や組込み系、システムプログラミングに違い領域の人は常用していたりする
これによってRailsはRuby処理系の人たちが多かったのでpry 人口が多かった気がする
でデバッガーの使い方なんですけどブレークポイントで止めて変数を観察して知識を得る、というのは基本的な使い方だが私の場合はそれ以外に２つの活用法がある
まずはブレークしたポイントにあるコンテキストを使ってその場でeval しながらコードを書く
外から初期化しづらいフレームワーク内部変数のインスタンスとかをそのまま使える
次はテストカバレッジの確認で、重要な分岐にブレークポイントを張ってからテストランナーを実行して意図どうりの値で通過しているかを確認する
通過してなかったらデバッグ中に変数を書き換えてどうやったら通過するのかをまたevalしながら試行錯誤する
実際のケースでは、モックと例外ジャンプと握りつぶしが発生してテストは成功しているけどコードは検証できてないのとかをこれで発見して直した
通ってるか自体はカバレッジレポートで可視化できる
あとwatch の機能はマルチスレッドで並列にひとつの値が書き換えられるようなコードで使うけど一般的なウェブサーバーの実装であまり出会わない
あとは巨大OSSの実行中プロセスを探検するとか
これはさながら美術館を音声ガイドつけながら観覧するような体験だと思う