プログラマーの方に質問でございます。

Question

プログラミングに関しての基本的な質問でございます。
プログラマーの方で他の人からエラーを直して！と言われたり、
自分でコードなどを書いているときにエラーが出た場合はどのような思考で解決していけばよいのでしょうか
サーバー、コーディングなどで考え方が違う気がしますが、（初心者のため安直な意見ですいません）自分はこうしてるよなどご教示頂けますと幸いです！

Answer 1

思考というより私のやりかたですが、私は能力が低いのを自覚していますので結構泥臭い感じで頑張ります。

他の方も言ってますが、まず、ソースよりエラーメッセージを見ます。
ほぼ必ず答えが書いてありますからね。

ソースは、自分が正しいと思い込んで書いているので見ててもなかなか気づけません。
(探しものは目の前にあってもなかなか気づかないですよね)

初心者のうちはエラーメッセージは、自分の悪口を言われているようで見るのがとても嫌でしたが慣れれば、友達です。(英語で分からないと思っても検索すれば、大抵先に誰かが同じことで悩んでます)

これを最初に誰かが教えてくれるといいのですが、いい先輩とかがいないとなかなかｗ

これでわからない場合、何もしなければ何もおきない(当たり前ですが)という前提で
問題が起きないところまで戻すなりコメントアウトするなり、バッサバッサと処理を止めていきます。

動くところまで戻してからエラーが発生するまで処理を追加していき、場所(行)を特定します。
一度書いた処理を消したりコメントアウトするのは労力が必要ですが、
眺めて悩んでいるよりも手を動かしたほうがずっと早い場合が多いです。
(時にはまるごと切り取ってエディタなりに貼り付けてバックアップしてから戻したりします）

行が特定できれば一番良いですが、出来ない場合でも、恐らくこの辺という場所に
ブレイクポイントをとにかくたくさん貼ってステップ実行を何度も何度もバカみたいに繰り返して、
本当に自分が思っている通りの処理になっているかを絶対見つけてやるという根性で探します。
諦めないということが何よりも大事

見つけられないわけが無い、探し方が悪いだけという気持ちです。
最初は、時間がかかりますが、やってるうちに勘が働くようになると思います。

なので、デバッガの使い方を自由自在に出来るようになることも大事です。
(マウスとかメニューでやるのではなく、キーボードショートカットで考えなくても手が動くくらい覚えます)

その日分からない場合でも翌日になるとあっさり分かることも多いので、
他のタスクがあれば先にそっちをやるのも有効な場合もあります。

どうしても見つからない場合は、代替手段を探しますが、あまりそういうことは無いです。
(探す場合はそもそもこの処理必要なのか？とか、他のやり方あるんじゃね？とか)

経験が少ないうちは、コンパイラとかがバグってるとか思う時も多かったですが、
大抵は自分の頭がバグってます。(というかコンパイラのバグを見つけたことないですｗ)

有名だと思いますが、私が好きな格言があります。(出典は知りませんが)

「プログラムは思った通りに動かない、書いたとおりに動く」

これを忘れないことだと思います。

Comments

[growthposition]

すばらしい格言ですね。
参考になりました！

諦めずに地道に探してまいります！

Answer 2

まず、質問とは関係ない話から。
言葉の定義として個人的にこう思います。
エラー → コンパイルエラーや実行中に起きる想定外の異常な状態（通信エラーなど）
バグ（不具合） → 実行中に起きるプログラマが仕込んだ処理誤り

質問者さまの言うエラーはどちらかと言えば後者ですかね。
その前提で。
解決までの道のりは私の場合、こんな感じです。

1. 現象の確認・聞き込み（どのような操作をしたかなどを発見者に確認）
2. 不具合の再現（自分で再現させてみる）
3. ログやデバッグメッセージなどがあるなら確認
4. 原因となるプログラム上の場所をログなどから特定（ログがない場合は操作方法などから追う）
5. ロジック確認
6. コーディングミスなのか仕様上の誤りなのかを切り分ける

バグはどんな上級者にもつきものですが、やはり初心者と上級者では発生頻度はかなり違うと思います。
推測するに、上級者の場合は、過去の経験に基づくコーディングをしているので新たなバグが発生しない、単体テストを入念に行っている、などがあると思います。
プログラムをたくさん書いて経験を積んで精進しましょう。

Answer 3

まずは、エラーメッセージを確認するのが先決です。コンソールで動かすアプリならその中に出ますし、Webアプリではサーバログに残るので、まずは「どこで」「どんな」エラーになっているかを把握しましょう（そういう理由で、「いちおう動くけど結果が違う」バグは追いかけにくいです）。

エラーの出る場所と理由がわかれば、あとはそこに来る引数とか周囲の変数の状況をデバッガで追いかけて、想定外の値が来ていたりする場合は事前チェックで除外したり、書き間違いは修正したり、といった感じです。

Comments

[growthposition]

エラーメッセージを確認する癖がついてなかったです。
こちら習慣づけます

貴重なご意見ありがとうございます！！

Answer 4

私の場合は、２分法と似たようなやり方をします。
例えば、a,b,c,d,eという処理が順番に実行されeで問題があるとします。そうした場合、まず、cまで実行して結果を確認します。で、cの結果が正常ならdあるいはcの処理に問題がある。cで問題があればa,bあるいはcに問題がある・・・と問題がかなり絞り込めます。
ただ問題なのは、実際の（私が扱うような：機能追加/修正が主 自分が作ったプログラムでも５年もたつと“誰のプログラム？”状態）プログラムは前記のようなきれいな流れになっていることは少なく、古いプログラムをメンテするような場合は、ソースそのものが修正に修正を加えられあっちに行ったりこっちに来たりｗなかなか特定ができない場合もあります。（ドキュメントすらない；；）とくに非同期処理などが入ってくると“毎回結果が違う”などというとんでもないことが起きます。まあそれはそれで、“受信割り込みが悪さしている”とかある程度目星が付くのですが・・・takashima20さんが仰るように、そう感じられる感（？）みたいなものがだんだん育ってきます。・・・時間が掛かりますが・・・地道にやるのが、結果として早道じゃないでしょうか

Comments

[growthposition]

ありがとうございます。
地道に手を動かして覚えていきます！

そのような思考法全く思いつきませんでした。

Answer 5

エラーと言われるものでも、色々な場合があります。
自分の意図と異なるプログラムの場合、仕様書の曖昧さや意味の取り方が違う場合、受けた説明と異なる場合等、色々なエラーが発生します。
最初の自分の意図と異なる場合は、自己責任として次回からテストを充分にするしか無いかな。

他人が関係する場合はコミュニケーションエラーも含まれて来るので、責任の所在と捉え方は人それぞれだと思います。
そんなときは共有できるゴールに到達する様に、いろいろと努力はしてみます。

色々な事件が発生しますが、今でも完成したものが使われている場面を見る喜びは有ります。

Comments

[cateye]

>完成したものが使われている場面を見る喜び・・・いいなぁこれｗ　私は工場とかの組み込みが多いのですが、出荷された製品を店頭などでみると“元気に動いてるんだな”とか思いますね。

[growthposition]

チームで作業する際には本当に色んなエラーが起きますよね。。

本当に全てのエラーを解決できるように精進します！！

そして、無事結果が出るところまでもっていきます！！

Answer 6

多くの人が参考にできる、いい質問内容だと思います！
私も本スレッドで良い勉強が出来ました。ご質問・ご回答ありがとうございます！

さて、私からの回答ですがデバッグの手法は皆さん書いてらっしゃるので、私からはデバッグの心構えをメインにお話しします。
このあたりは個々の考え方があると思うので、参考までに。

特にJava系（他にもいっぱいあります）を触っていたらそうなんですが、ひとつ、一箇所、１文字間違えただけでもとんでもない量のエラーメッセージが出てうわぁ…ってなるんですよね。
エラーメッセージが英語というだけですぐに「java ○○ 実装 コード」とかで調べてました。
もちろん、こんな調べ方なのでヒット率は微妙です。

ただ、落ち着いてエラーメッセージを見ると（この段階ではまだ読んでない）なんかいつも同じやつが出てくるな～、と気付きます。
とりあえずいつも出てくるから調べてみるか、と思ってgoogleでそのエラーメッセージを「意味はとりあえずわかんないし、そもそも読んでないけど検索」します。
そうすると、日本語でこうしたらいいよ、という「考え方を教えてくれるサイト」に到達できます。
→ここでは問題解決が出来なくていい、という開き直りで。
とりあえずエラーの意味が徐々に分かってくるので、自分のシステム（仕事）の場合はここかな？と適当にアタリをつけてみます。
これだけでも大きな進歩です。

そうですね…
たとえば、FileNotFoundExceptionなんてとてもイージーな（理由を突き詰めると沼だったりしますが…）内容です。
普通の英語なので読めば分かりそうなものを、こういうレベルすら読まずに検索を掛けていました。
が、上に書いたとおり、この程度なら原因が何かなんて見れば分かるレベルなのです。
そうすると、「エラーメッセージとか大したことなくね？」と自分に変な自信が出てきて、IllegalなんちゃらExceptionみたいなのにも取り組んでいけるようになるのです。
このフェーズに入ってきて、ようやくエラーメッセージの英語を読み始めました。まだ理解はしていませんが、少なくとも「記号」から「文字」に変わった瞬間です。

その後、様々なエラーとの格闘経験が出来て、最近だと予想できるExceptionはなるべく自分で回収して解決の手引きになるようにフレームワークなりルーチンを組むようにしてました。
今考えるとそれはそれでまた別の問題があるのですが、ここまで出来るようになってくると大体のエラー系の意味とかは何となく分かるようになると思います。

今はもうJavaを使っていませんが、考え方は根付いています。
がんばって！

Answer 7

僕も最初は何かバグが起きるたびに、そんなバカな、と信じられなかったり、
焦っていましたが、ひとつずつ考える、ということを意識すると
解決が早まりました。
ここが動いているのであれば、ここまでは確実に問題ない、とか、
動かしているメソッドを単純化して、関係なさそうなところは全部コメントアウトしたりして
原因を絞っていく、ログを仕込んで確認、等でどこまでが担保出来ていて、
どこからは確実に動いていない、等絞っていくことが大事かと思います。
あとは例外が発生するのであれば、そのままの文言をコピってググると
意外と同じ問題で苦しんだ人のブログが見つかったりします。
ググるだけであれば、職場でも問題ないところは多いですしね。
経験が増えると、このエラーは、この辺が怪しい、という勘もついてきますね。

Answer 8

入力があって出力がありますよね。
出力が正しくないなら入力から出力までの何処かがおかしいのです。
プログラムを眺めている人がいて間違いを発見できない人は「正しいよなぁ」と思って見ています。
私は、どこかがおかしいと思って見ています。ピリオド１つで意味が変わることもあるし、
1文字左右にずれているだけで意味が違いこともありますので。

なので、新聞やTVのテロップ、来たはがきの文面など、よく読み込まなくても「ここ間違っている」
と、誤字脱字を発見することができるようになっていますね。

「お支払いいたします。」の「い」が1個しかなかったりですね。

Comments

[growthposition]

細かい点が大事になるのですね！

常に疑ってかかる姿勢を忘れずに精進してまいります！

ありがとうございます。

Answer 9

「突然○○になった!!」
というのをよく見かけますが、だいたいなにがしかの原因がありますよね。
まず、自分or仲間が直近でなんかやってないか?
ってことで、やってたらそれを元に戻してみる。
あとは、外部要因として何か変わったことはないかと
地道に調べるんですかねえ。
経験値が増えてくると、なんとなくハナが利くようになるもんです。
数をこなしていけば… と、まあ、特効薬はないって話で。(^_^;

Comments

[growthposition]

そうですよね。
ここで皆様に考え方を教えて頂けて幸せです！

Answer 10

最初はよくなさそうな部分のコードなり設定なりを見てテストします。
目論見が外れたまたはよくわからなかったら、ここまではうまく言っているはずだと思う部分をテストします。
うまく行っていなければ、もっと前のうまく行っていない部分を探します。
ここまではうまく行っているという部分が見つかればまた、あたりをつけてテストします。

それでもうまくエラーの原因が分からなければうまく行っていないものをまるごと捨てられないか考えます。

かなり地味さ検索方法ですが、どれだけ考えずに連続してテストし続けられるかが勝負だと思っています。

テストを続けている内に、エラー箇所をひらめくことが多いです。じっとコードを睨んでもエラーの原因に当たることは少ないように感じます。

Comments

[growthposition]

今までずっとコードを眺める作業をしておりました。
改めます！

ありがとうございます！！

[iwamoto_takaaki]

あくまで私の場合ですので、眺めたほうが早い人もあるかとも思います。私の場合は、問題ない場所をじっと眺めて、思わぬところにバグがある場合が多いらしいという経験からくるものです。

[cateye]

眺める事についてですが、納品も終わってとりあえず終了ｖ＾＾　なんて状態で、ぼけ～～～っとソース見てるとなんか変？？；　なことに気が付いたりします。バグではないのですが、バグの温床になりそうな部分っていうか・・・なんとなく違和感があるっていうか・・・納品済みのソースはいじれないので文書を残すとかしてますね。

[iwamoto_takaaki]

ありますねー。

バグフィックスのタイミングだと、真剣すぎるから、違和感なんか感じられず、終わってしまうまでぼけ～～ってみれないんですよね。

私は社内SEだったので、簡単なものなら修正してユニットテスト書いてほかのリリースのウォークスルーでしれっと承認もらっていました。