Effective Debuggingでプログラミングに関わる問題解決力を高める

Effective Debugging を読みました。

システム開発に関わるバグの調査時間は馬鹿にならない量になりがちだと思います。
この解決時間は調査担当者の解決能力に強く依存します。
同じ問題を一瞬で解決する人もいれば、いくらかけても解決できない人もいます。
はじめからエラーメッセージを読まない猛者もいますよね（青筋つきの笑顔）

熟練開発者のデバッグ技法や考え方を学ぶことで
この解決時間を短くし解決率を上げていく。
そのスキルの学習効果はとても高いのでは無いでしょうか。

気になった項目

問題に対する洞察を得るにはウェブで焦点を絞って検索する

皆それぞれのやり方でやっているが、あまり表で語られることがない部分だと思います。

• エラーメッセージをダブルクォーテーションで括って検索する
• ライブラリの名前やクラス、メソッド名で絞り込む

などは、おそらく多くの人がやっている方法だろうなと思います。

• searchcode

OSS のコードの中身を調べる際に GitHub を調べる人は多いと思いますが、
searchcode というものがあることを知りました。
次に調べる機会に使ってみます。
searchcode 略すとサチコだけど Google Search Console = サチコの俗称と被るのでダメだな。

• 多くの問題はたいてい他の人が先に遭遇しているので見つからないときは調べる方向性自体が誤っている

何となく感じていましたが文章として形になっていると改めて強く意識することができそうです。
知見を多く持った仲間に相談するタイミングかもしれませんね。

変更から結果までのターンアラウンド時間を最小化する

• デプロイ自動化
• 検証用のテストプログラムの作成・実行の自動化

などによりバグの調査検証のターンアラウンド時間を最小化するという話。

何となく意識できているときと、そうではないときがあり
手動実行でこねくり回していることもあるので問題解決フローに組み込みたい考えだと思いました。
数回の試行で解決しないものや、はじめから解決困難であることが見えている問題に対して適用しようと思います。

まとめ

ここにあるようなデバッグ技法は

• ペア作業により熟練者から習う・盗む
• 地頭が良く、場数を踏んでいる開発者が自らたどり着く

などの習得パターンが多いだろう、と予想しています。
また「怠惰な気持ちが強いため、めんどくささに敏感」という気質も重要そうです。

逆に、上記に当てはまらないケースに習熟するには独力だと難しい面があるように感じます。

• 見本になる相手がいない
• 自らこの書籍にあるものと同等のものを閃くほどの地頭はない

などですね。
気質的には「勤勉過ぎて、めんどくさいことに鈍感」というのもありますね。

地頭がいい人に関してもこの本にのっている手法のうち知らないものもあると
思うので役に立つと思いますが、特に後者の人に強くおすすめできる本だと思いました。

書籍

Effective Debugging ―ソフトウェアとシステムをデバッグする66項目