Bugって何？食べられるの？ 🐞

Bugとは、ソフトウェアにおける不具合や障害のことで、プログラムが期待通りに動作しない原因になります。

（機能が違う、結果が間違う、クラッシュする、ユーザー体験が悪くなる…など）。

「Bug」という言葉が有名になったのは1947年の出来事からです。

Harvard大学のMark IIというコンピュータに本物の蛾が入り込み、故障を引き起こしました。それ以来、プログラマーたちはソフトウェアの不具合を「Bug」と呼ぶようになったのです。

バグの分類

バグにはいろいろな分類方法があります（分野別、重大度別、開発工程別…）。

ここでは「原因別の分類」を紹介します。原因から考えると、対処法を見つけやすいからです。

Syntax Bug: 構文エラー（セミコロン抜け、カッコの対応ミスなど）。

Logic Bug: ロジックの間違い（条件式が誤り、無限ループなど）。

Runtime Bug: 実行時にのみ発生（ゼロ除算、メモリオーバーフロー、ヌルポインタなど）。

Semantic Bug: コード自体は動くが、要求を誤解していて結果が間違うもの。

バグに会ったらどうする？

1. 落ち着いて分析する

焦らずにエラーメッセージを読み、ロジックを確認。

セミコロン1つや未宣言の変数、タイプミス1行でプログラムが落ちることもあります。

2. 問題を分割する

バグを起こしている部分を切り出して、小さく動かしてみる。

そうすることでエラー箇所を特定しやすくなります。

3. 資料を調べる

Google、StackOverflow、GitHub、あるいは公式ドキュメント。 大抵のバグはすでに誰かが経験しており、解決策がシェアされています。

4. 休憩する

散歩したり、水を飲んだり、仮眠したり。

頭をリセットすると、思わぬ解決策が浮かぶこともあります。

5. 仲間やコミュニティに相談する

恥ずかしがらずに共有しましょう。

第三者の視点が、自分の見落としを気付かせてくれることがあります。

👉 結論：バグに遭遇することは失敗ではなく、思考力を鍛え、知識や問題解決スキルを伸ばすチャンスです。大事なのは忍耐と冷静さです。

私の「バグ処理法」

ステップ1: 5分間、瞬きせずに画面を凝視する。

ステップ2: 同じコードを書き直してみる。「…勝手に直らないかな」と期待。

ステップ3: 「なぜコードが動かないのか？」とGoogle検索 → 100万件ヒット。

ステップ4: コーヒーを淹れて戻る → バグはまだそこにいる。

ステップ5: 同僚に相談 → 5分後「え、セミコロン忘れてるだけじゃん」。🤦‍♂️

👉 教訓：バグは敵ではなく友。むしろ「親友」です。

バグが多いほどスキルも増える。焦らず、まずGoogle → それでもダメなら仲間に相談 → 最後は寝て、明日また戦えばいいのです 😎。