バグとの戦いで心が折れない為のコツ

Question

Rails初学者です。現在岡山県の為主にオンラインで独学しております。
悩みとしては、特に教材の演習でバグが出た時、どこに聞いても答えが見つからず心が折れそうになります。

＊Slackで仲間に聞く
＊ググりまくる
＊1Step前まで戻ってやり直す
＊エラーメッセージからバグの箇所を推測する

以上全部試してダメだった場合どん詰まりになり、
現在諦めるしかない悲しい状況なのですが、
他に問題を解決するうまい方法があるのでしょうか？
是非お知恵をお借りしたく思っております。

Answer 1

タイトルと内容が一致していない感じで、かなり迷われている感じがします。

バグを正しく潰すには、バグ一点に注目する前に、処理全体を俯瞰する事も必要です。
何故問題が発生したのか。
原因は、単に部品の動作不良なのか、それともシステム的に不備があり部品に処理できないデータを通したのか。
全体の俯瞰から、より小さい範囲にフォーカスを絞っていく必要があります。

そうすることで、処理する為の目処を立て易くなると思います。
目処が立たない状況が長く続けば、そのうち心が折れます。
※狭い範囲から拡げる方法だと、処理の粒度の問題で考えをまとめ辛くなります。また、どこまで拡げれば良いのか…と途方に暮れれば心も折れます。

問題を解決するにも、バグと同じで全体（より広い範囲）を把握することが大事です。
今回の場合、書籍・演習という範囲で見ていますが、そもそもRailsのどういった機能を理解する書籍・演習でしょうか。
他の回答者の方も指摘されていますが、それを理解するのに別の方法がないか検討することも必要です。

迂遠でも一番良いのは、Rails全体をまんべんなく把握できるようになることだと思います。
特に、指導してくださる方が近くにいらっしゃらない状況のようですから、ご自分である程度全体の動作を把握しておく必要があります。

逆に学習効率を考えるなら、専門の学校等の利用も視野に入れる。業務を視野に入れているなら専門知識を持つ人材の雇用を考えた方が良いかもしれません。
※雇用の場合は、空いた時間に教えて貰う。という手も考えられますが…

Answer 2

バグに振り回される人とそうでない人の一番の違いは「着眼点」の違いです。
換言すれば、バグの原因を嗅ぎつける『嗅覚』の鋭さです。

ここがいわゆる「スキルの差」として一番大きなところだと思いますが、プログラミングそのものについてコツコツ学習していてもなかなか身に着けにくいところでもあります。

バグで心が折れないようにするには、早く「バグに振り回されない」ようになれば良い訳ですが、そうなるためには「バグが解決」しただけで満足していてはいけません。『嗅覚』を意識的に訓練する必要があります。

ご参考になるか分かりませんが、そのために自分が日頃心がけていることを列挙してみます。

1. まず落ち着く（慌てずに俯瞰する）
2. エラーメッセージ（不具合の症状）を、たとえ良く分からずとも「よく見る」
3. コードを分割してエラー発生箇所の「候補」を限定する
4. 自分を疑う
5. 質問した時は、回答そのものよりもその回答に至った「プロセス」に注目する

以下は、（かなり長くなってしまいますが）補足説明です。

1. について

表示されているエラーメッセージや現れている不具合は、直接の原因ではないことが多いです。
つまり真の原因は別のところにあって、その影響で現れている症状を目にしているというケースが多いので、俯瞰する余裕を持たないと的外れな対応に終始してしまう危険があります。

1. について

表示されるエラーメッセージの多くは英語ですし、見たこともない用語が幾つもあると、それだけで心が萎えてしまうものです。
しかし諦めずに落ち着いて良く眺めてみると、意味自体は分からずとも、徐々にどの単語がキーワードになっているかが分かるようになってきます。それがWebで検索する「スキル」に大きな差を生み出します。
さらに重要なこととして、意味自体は分からずとも、たとえばメッセージのフォーマットやエラーコードの特徴から、どこから表示されたエラーなのかが分かる場合が多いです。
たとえばOS（WindowsやLinux）が出したメッセージだとか、DBMS（MySQLなど）からのメッセージだとかが区別できると、大きなヒントになることがあります。

1. について

元々、コンパクトなモジュールに分割し、テストしやすい実装にしておくべきなのですが、一連の処理に関しては、コードの後半を大胆にコメントアウトしてしまい、この部分までは想定通りの結果になっている、この変数の値はこの時点までは正しい、などのように確認することで、バグの可能性を排除して行きます。

たとえばコンタクトレンズを落とした時に、慌てて手当たり次第に物を移動すると訳が分からなくなるばかりか大事なコンタクトレンズを壊してしまう危険もあります。
同じように、闇雲にコードをいじりだすとアッと言う間にカオスな状態に陥ってしまいます。

ですので、なるべくそっと（＝現状を変えないよう気を付けつつ）コードを分離して、白／黒を判別し、調査範囲を絞って行くことが重要です。

1. について

自分自身の目や理解を過信せず、確認する際には目視に頼らない、３回確認して分からなければ「確認方法」を変えるなどです。

たとえば、パスや変数名の単純なスペルミスに気付かず長時間嵌ってしまうという場合が極めて多いです。
それで目視に頼らず、パスであれば実際に手を動かし ls コマンドでファイルの実在を確認してみるとか、変数名であればエディタの検索機能を利用するなど、必ず機械的に確認します。
また、二つのパスを比べる際にも、縦に（２行に）並べてみると、違いが一目瞭然です。
仕様書やコマンドリファレンスも、先入観を捨てて良く読むと、とんだ勘違いだったということも少なくないです。それが人間というものです。

1. について

「オンラインで独学」だと難しいかもしれませんが、自分が一番重要視しているのはこの点です。

たとえばバグが解消せずに嵌っていて、先輩に質問したとします。
その時、自分だったら、ただ回答を待つということは絶対にしません。
先輩がプログラムを調べる際に、

• 画面をどのようにスクロールしているか
• 視線をどのように動かしているか
• 変数の値を確認する際に、どの順序で確認しているか
• 動作確認のために、手をどのように動かしたか

（具体的にどこをコメントアウトしたとか、どこにブレークポイントを設定したとか等）

先輩から教わる度にこれらの一見些細な点を注視していると、いわゆる「できる人」はバグを発見するまでの「プロセス」に全く無駄がありません！！
そういうことに改めて気付くと非常に感動します。自分もぜひそうなりたいと強く願うようになります。
これこそが、お金を払ってでも身につけるべき宝（スキル）だと思っています。

ネット経由で質問する場合には、もちろん「視線の動き」を観察しようがないですが、鍵は「オヤッ！？」です。
つまり、どこの部分に「オヤッ！？」っと感じて解決に至ったのか、という部分が非常に重要です。

これらの点に注力しつつ、その上でバグを作り込んでしまわぬようにするための工夫（Tips、先人たちの知恵）を習得して行けば長足の進歩を遂げられるに違いありません。

言語は異なりますが、端的な例を一つだけ。
C言語の場合、下記の①（比較演算子）と②（代入演算子）は
① if ( x == 0 ) 〜
② if ( x = 0 ) 〜
どちらも文法的に正しくエラーは出ないですが、結果が全く異なります。発見しにくいバグの典型例です。
この時、もし下記のようなコーディング規約に則れば、
①’ if ( 0 == x ) 〜
②’ if ( 0 = x ) 〜
②は文法エラーとして機械的に排除することができます。

以上のような努力を続ければ、程なくしてバグに振り回される悪夢からは解放されると思います。
油断すると、また思わぬ落とし穴に嵌ってしまいますが。。

長くなりましたが、以上、ご参考になれば幸いです。

Comments

[DaisukeIshii]

詳細なご説明誠にありがとうございます！
頂いたアドバイスを基に、理解が深まりましたので、
引き続き足元を固めて学習を進めて参ります。

Answer 3

teratailなどで質問する、もあると思います。

また、デバッグというと、

1.問題の再現条件を確定する。
2.問題発生時の情報を収集する。
画面に得るエラーメッセージをみる、
ログを見る、デバッグログを入れてみるなどが当てはまります。
3.原因を推定する(仮説を立てる)
ログのエラーメッセージでGoogle検索してみる、デバッグログから、
データが想定外になる箇所を特定する、なども含みます。
4.推定した内容が当てはまるかどうか確認する。当てはまらなければ2に戻る。
5.対応方針を検討する。
6.方針に従って修正する。
7.問題が解消されたかどうか確認する。

再現条件が中々明らかにならないケースもあり、
その場合は再現条件の確定を後回しにしたりもしますが、
概ね上の流れと思います。

DaisukeIshiiさんが挫けそうになるには、
大体3.でしょうか？

この段階で出来そうなこととしては、
0.エラーメッセージを出している箇所のソースを見ることが出来る場合は、ソースを見る。
0.(もしやっていなければ)Google検索の範囲を英語まで広げてみる。
0.処理の流れを追いながら、どこまでが想定通りで、どこからが想定外になっているかを確認する。(要所にデバッグログを入れたり、デバッガを見たり)
があると思います。
どういうケースが多いか教えてもらえれば、
そのケースでどうすると良いか、書けるかも知れません。

また、この書籍は分厚いですが、デバッグのやり方が書かれていて、
参考になるかもしれません。

Answer 4

「プログラミングは楽し、デバッグは苦し」で、
コーディングよりデバッグのほうが難しいです。

とくに「心が折れない為のコツ」は、賛否が分かれるかもしれませんが、
学習なのでべつにスルーしてもいいです。仕事だとそうはいきませんが。
RPGで序盤で不条理に強いボスに遭遇して全滅するみたいな感じなので。

しかしもし、それが「逃げ」に思えて納得できないなら、
バグが出た環境をまるごと保存しておいて、
問題集だと思って後でまた挑戦してもいいと思います。

デバッグには書く力より読む力が必要ですが、
最初のうちは読む経験が不足しているのです。
読む経験を積むと自然と分かるバグもあります。

もう少し正統派の回答もしておくと……、
デバッグの多くはバグの原因を特定する作業です。

それにはいろいろなやり方がありますがたとえば、
バグが出なかったときのコードと出たコードを比較します。

「1Step前まで戻って」もバグが出るなら、さらに前に戻します。
もしバグ出現前のコードが保存されてなかった場合、
Gitのようなバージョン管理ソフトを導入します。

別の角度からも言うと、モダンなプログラミングでは、
そもそもコーディングの時点で
バグの対策を先回りしてする発想になっています。

まず可読性を良くします。そしてモジュール化やカプセル化で、
潜水艦の隔壁と同じように、バグが他に浸水しないようにします。
またテストは先回りでする一種のデバッグと言えるかもしれません。

これらの目の前のバグを追い回さなくて済むやり方も重要です。
虫がはい回るのは誰しも嫌でしょうが、虫を一匹一匹追うより、
虫が湧かないよう衛生的な環境にすることで一気に駆逐できます。

Answer 5

バグとの戦いで心が折れる

というのは、ズバリ言いますと、分からない、出来ない事で心が折れてるのかと思います。
デバッグも出来て、バグも自分で解決できれば、それによって心は折れないのではないかなと考えます。

つまり心が折れない為には、
「デバッグが出来て、バグを自分で解決できるようになる」
本質的にはこういう事なのかなと思いました。

デバッグに関しては、私も最初は難しいと思います。
他の方も書かれてますが、ある程度のコードを読む力が必要です。どういう順序で処理が流れるかなど全体を俯瞰できることも重要です。
ただこういう部分は、今後上達していく上で避けて通れる部分ではないので、少しずつ身につけていくしかないでしょう。

教材の演習をやる際にも、ただ単に「教材が動かない。バグだ。」ではなくて、「どうしてそう書いたら、そういう挙動をするのか」などを一歩一歩把握していくことからではないでしょうか。

私の意見としては！
心が折れないためにどうするかより、どうやったら出来るようになるだろうかを考える！

---

余談。正直なところ。

バグで心が折れないようにする方法ではなくて、「Railsで◯◯をやっていて、こういう実装をしてるが、うまく動作しない」みたいな質問をすれば、解決するし、心も折れないしで、一石二鳥だったりするかも♪

Answer 6

とりあえずprintfデバッグで各所の値が予想通りの値になっているか確かめてみてはいかがでしょう。

Answer 7

試行の中に含まれていないのは「参考書を買って読む」ですが、私はずいぶん参考書に助けられました。
悩んでいる時間と、参考書の料金を比較すると、いつも「早く買えばよかった」と思います。
少々難しい上級編でも、お守り代わりに買ったりします。

開発環境の充実によって非常にデバッグの助けとなりますので、そのあたりも色々トライしてみるといいかも知れません。

めげずに頑張ってください。きっと今の苦しみは将来役に立ちます。

Answer 8

特にプログラミングを学び始めたばかりの方は便利なツールを知らないですよね。例えばRailsだとPryを導入していると動作中の変数とか出力できてかなり開発が捗ります。

今更聞けないpryの使い方と便利プラグイン集

こういった情報をキャッチアップしようにもやり方がわからないと思うので、teratail等で質問したり、気になる人のtwitterをフォローしたりして、人に質問するのが良いです。1人や、周りの人だけで抱え込んでも中々バグを潰すのは難しいこともありますから。

がんばってください。

Answer 9

どんなに頑張っても、原因がわからないことは、
いわゆるスーパーハッカーでない限り、あると思います。

重要なのは、代替案を探せるかです。
そのバグを修正できなくても、別の方法で解決できるなら、それで実装してもいいと思います。

根本原因を探ることは重要ですが、
（わからないままにしておくと違うバグを生むので）
ある程度調べたら、割り切って違う道を探すのもアリだと思います。