デバッグの話
ごみが増えて、もう捨てる場所がありません。どうしますか。
こんな問題も今回のデバッグ話の範疇
デバッグ:問題解決は、知的機能の中でも最高に複雑
問題の認識(定義)
原因の調査と分析
解決策の立案
実施
結果の評価
...
---
(言いたいこと)
時間なり労力なりお金なり、一番かかるのは「考える」コスト。
で、できるだけ考えたくないから、どうしても考えるということを最後の手段と捉える傾向があるね。
じゃあ、問題が起きたときのことを考えるよ、となっても
実際にはそうでないことが多いね。
実際の問題解決が必要ない、自動的な生活がデフォルトになっているから...
問題はどうであれ、グレーなことに無理はしないね。
(問題発生の原因を突き詰めると無限にあってよくわからなくなりがち(切り捨ての閾値を見失いがち))
問題解決は必ずしもうまくいったり、それを楽しんでいるというわけではないね。
実際には、問題解決を避けてきたのであると。
言い換えれば、ごみが増えた原因を調べて、対策を考えるよりも
穴を掘るほうが簡単であるということ。
考えもせずに堀り続ければ、穴はどんどん深くなるばかり。
深くなればなるほど、多く投資することになるね。
困難を深堀するということは、タスクに不均衡な時間を費やしてしまうことに。
それは自分たちがやっていることの重要性が、論理自体が歪む。
ごみ増加の原因は、Xにあると仮定して調査を開始しました。
実際には原因は他にある事がわかりました。
つまり、最初の勘は見当違いであることが判明しました。
それ自体に問題はないということ。
間違った仮定の下で、時間を費やす事は理想的ではないが、よくあるね。
仮説に疑問を投げかけるのを辞めて、例えば自ら投資を始めた時にリソースの配分ミスが始まる。
しかしながら、そのような事が起きた場合にそれに対処するためのシステムを、手段を我々は持っています。
要約
デバッグ作業は、多くの場合、歪んでしまい、自分たちが困難な状況に陥ってしまう。生産性が落ちてしまう。
これは、自分が解決に導びかない簡単で反復的なことを繰り返してして、問題解決にならないから。
自分が何にスタックしているのか理解できるようになってください。
困難な状況に陥るような兆候を知り、うまく抜け出すようになってください。
事前の計画、デバッグ手法の学習、一度歩みを止めることなどが正しい方向に戻るための手段
---
---
(→ ...デバッグの話から少し逸れる)
---
問題の「解決方法」をどうやって考えたらいいのか？ という話
(考え方の「手法」の話)
例えば
解き方が何もわからないような問題に出くわしたとき、
とっかかりもなくて、どうすればいいのかわからず固まるしかない、みたいな状況になってしまうこと
ありますよね
問題の解決方法がわからない、解決方法の考え方もわからない。見当もつかない
そもそも問題（問題の意味）がわからないこともありますよね
どうしたらいいのか？
そういう状況のとき、どうやって考えたらいいのか
↓
(アンサー)
→「問題が何も分からない時」の考え方の手法
問題を細かく切り分けて分析したり解決方法を導くための考え方として、
以下のようなものがあります。
①FTA (Fault Tree Analysis)故障の木解析
②FMEA (Failure Mode and Effects Analysis)故障モード影響解析
順番に見ていきます。
(以下、↑のページを読んだメモ です)
①FTA(Fault Tree Analysis)
「故障の木解析」というもので、
事故や故障が起きたときの原因解析に用いるものです。しかしまあ、単に中身を置き換えれば問題解決全般に使えます
FTAはFault-故障 Tree-木 Analysis-分析
故障が一番上にあって、その下に「なぜ？」をやっていく「トップダウン方式」である
本当のFTAを説明しようとすると「故障モード」っていうものについての説明が必要になったり確率の話が出てきたりで相当だるいので、ここはシンプルに簡略化します。
FTA(故障の木 解析) を使った考え方は
故障を最上部に置いて、その下にツリー状に「なぜ？」を並べていきます。
例えば、
「エレベーターが止まってしまったという故障を解決したいとします。
故障の原因は「荷物を載せすぎた」こと だったとします
解決方法は「載せすぎた荷物を下ろす 」こと
→何もわからない状態 から ここまで、 どうやって考えを掘り下げていけばいいのか？
例)
(故障)エレベーターが止まってしまった。
なぜ、止まったのか？
「止まってしまった」ときの状況はどんなだったのか？どんなタイミングで止まったのか？
どんなときに、エレベーターは止まるか？
例えば、
→荷物を載せすぎたとき
→停電したとき
...
このように、問題を少しずつ分解していくことで
少しずつ、考えを掘り下げていくことができるでしょう。(おわり)
それぞれの「なぜ？」にまた「なぜ？」がぶら下がっていく感じですね。
(問い を考えるときのコツ )
なぜ？ なぜ？ と問い続けると人は言い訳を探してしまう。
そうではなく、何が？ 誰が？ と具体的に問題を探せば答えが見つかる。
例：Ｑ：会社で人から頼みごとをされると断れないんです。
なぜですか？
⇒人から嫌われたくないからです。
↑これでは単なる言い訳を導いてしまいます。
②FMEA(Failure Mode and Effects Analysis)
「故障モード影響解析」なんて言ったりします。
FTAとは反対でボトムアップで故障の分析を行う手法です。
つまり「それぞれの故障要因が他の（上の）要素にどれくらい影響を与えますか？」っていう考え方で、
現場の小さなミスや不具合から最終的な悪しき結果にどう繫がるのかを考えるイメージです。
荷物を乗せ過ぎればエレベーターが止まる要因にはなるけど、それが他の「もっとひどい故障」を引き起こす要因にはなりません。荷物を降ろせばエレベーターは動きます。
こうやってそれぞれの要素（故障モード）から起こり得る故障を考えていくっていう感じです。うーん、ちょっと例えが下手くそかな。すみません、あんまり良い例が思いつかなかったです。
長々とつまらん説明をしてしまいましたが、これをどう使うのかというと、やっぱり「日常的になぜなぜ分析を上からも下からもやる癖を付けましょうよ」ってことかなと思ってます。
物の考え方は段階的であるほど理論が崩れにくく一貫性が保たれやすいです。その順番が細かいほどその思考の精度は上がるでしょう。
(FTAとFMEAの話 おわり)
---
(読み物)
「.NET & Windows プログラマのためのデバッグテクニック徹底解説」
「バグ」とは
私はバグを、「バグとはユーザーに苦痛を与えるもの」と定義しています。
私はこのように定義できるバグを、次のようなカテゴリに分類しています。
・一貫性なきユーザーインターフェイス
・ユーザーニーズを満たさない仕様
・低劣なパフォーマンス
・クラッシュとデータ喪失
バグの発生原因は大まかに、次のようなカテゴリに分類できます。
・厳しすぎるスケジュール
・コーディング先行型開発
・不完全な要求定義
・技術的な無知
・低いモラル
最高のデバッグ方法
→ (結論)
最良のデバッグ方法は、
バグを発生させないような開発姿勢を身に付けることです。
適切なプロジェクト計画を立て、品質にこだわり、そして、製品開発に必要なテクノロジ、OS、CPUなどの知識を深めておけば、デバッギングに要する時間を最小に抑えることができます。
"私が推薦するデバッギングアプローチは、次のような9つのステップで構成されています。
図1－1にデバッギングプロセスを構成するステップを図示します。"
https://scrapbox.io/files/64f94bad980146001ba4b7ac.png
▲ 図1－1デバッギングプロセス
👇デバッギングプロセスのステップ`、9ステップ
ステップ1：バグを再現する。
ステップ2：バグ内容を書き留める
→ステップ1とステップ2は、避けて通れません。
ステップ3：バグの原因は自分にあるとする。
ステップ4：細分化し、征服する。
ステップ5：創造的に考える。
ステップ6：ツールを活用する。
ステップ7：詳細デバッグを開始する。
→ステップ3からステップ7までの
いずれかのステップでソリューション(解決方法)を見い出し、バグを除去できるはずです。
ステップ8：バグの除去具合を検証する。
ステップ9：デバッグ内容を記録する。
(おわり) →デバッグが完了 (問題を解決できた)
→問題とその発生場所がはっきりしているときには、 いくつかのステップを割愛してもよいでしょう。
そのような場合、
バグ修正後、ステップ8に飛び、修正コードをテストするようにしてください。
---
デバッグ時のコードリーディングのコツ
デバッグ時は
「これ変数いらないのでは...」とか
「英語変だろ...」とか
「ここいずれバグりそう...」とか
「え、なにこのメソッド名、中はどういう実装なんだろ」とかは、一切考えてはいけません。
今のあなたの仕事には関係ありません。
→デバッグとリファクタは分けて考えましょう
バグ調査はよく知らないコードと向かい合うことになりますが、
あちこち見てると脳内もエディタで開いたファイルもスタックが増えて調査の質が下がるし、時間もかかります。なにより残念コードを正面から見るとメンタルがやられます
集中して躱して躱して、ロジカルに一直線に愛しの🐞の元にたどり着きましょ.