理解駆動バグ解決モデル(メモ

注意事項

・体験から考えて作ったものです。
・僕はバグ解決のプロではありません。
・個人の創造メモ。

動機

　プログラマーとして調べながら機能を実装する時、よく時間を大量に溶かしてしまう現象をなんとかしたいと思った。

できたモデル

自問自答の結果をまとめた。

これを、『理解駆動バグ解決モデル』と名付けることにした。

理解を中心にバグの修正は行われるという考えをうまく表せたと思う。
図の右側にある『……』は、右にも同じような仮説の部分がたくさんあることを示している。

①〜⑤の説明をする。

①現状のバグに対する理解から仮説を構築する
②仮説の検証を行う
③仮説の検証によって得た理解を自分の中に蓄積する
④理解をもとに実装を行う
⑤実装を行ったことによって得た理解を蓄積する

一通りの流れを書いたが、必ずしも順番で行われるとは限らないものとする。
思いついた仮説からやるよりかは、現状立てた複数の仮説のうち、最もクリティカルなものから選んだ方がやはり効率は高くなるに違いないだろう。

また、仮説の検証によって理解が進んだとしても、実装するに足る理解が足りていなければ、適切な実装はできないので、現実には①から③を繰り返してから、④、⑤を行うことになる。

次に、この流れの中でつまづく要因を列挙する。

バグ解決が頓挫する原因考察

①の障壁
シナリオ１：理解不足による適切な仮説設定ができない
バグに対する理解・誤認識、フレームワークやライブラリ、プログラム言語などに対する理解不足が原因で解決に直結するような仮説設定ができないパターン。
理解が足りないので、おそらく無理やり仮説をアウトプットをするよりもドキュメントを読み込んだり、基本を学んだ方が効率が良いのではないだろうか。

シナリオ２：適切な仮説を設定できるレベルに問題が分割されていない
修正しようとしているバグが複数の要因が絡み合って起きているのだとしたら、適切な仮説を立てようとも検証が難しくなってしまうだろう。
仮説は分割可能な最小単位にしてしまうのが良いのではないかと考える。

シナリオ３：仮説の設定が下手
的外れな仮説ばかりを立ててしまうパターン。必要な知識と論理性と仮説設定の経験が必要になってきそう。

②仮説検証フェースの障壁
シナリオ１：仮説が検証できる形で立てられていない
そのまんま。

シナリオ２：調査するのが下手
調査スキルが未熟で調査するべき内容を探し当てられない、また、英語ができないせいで、少ない日本語情報にしかアクセスできないパターン。
Googleは英語で質問形式で質問すると答えと思われるものをサジェストしてくれる機能がある。こんな感じで検索エンジンに対する理解も深めていければ調査力が上がるのではないかと思う。

シナリオ３：仮設検証自体に対する理解の欠如
説明略。

③仮説の検証によって得た理解を自分の中に蓄積する
シナリオ１：得られた知見を意識して自分の中に蓄積しようとしない
記憶は意識して定着させようとしないとあまり身につかない。せっかく得られた知見も定着させようという意識がないともったいないと思われる。

疲れたのでまた気が向いたらまとめて理解を深める。
やっぱり文を書くのは疲れる……。