• 75
    Like
  • 0
    Comment

この記事は、Life is Tech ! Advent Calendar 2016 の14日目の記事です。

はじめに

はじめまして、Life is Tech ! ではMinecraftプログラミングコースのコースリーダーの他、黒ポロメンターとして活動しているラルフというものです。

黒ポロメンターとは:
ス○バの黒エプロンのLife is Tech ! 版
技術力が長けていたり、Life is Tech ! に対して大きなコミットをした人などが認定される仕組み。現在10名ほどが認定を受けている。

黒ポロメンターに必要な力

技術力はもちろん、教える力など、必要な要素は多々ありますが、個人的に重要視しているのは エラーの解決能力 です。
メンバーやメンターなどから来た質問から如何に正確に、素早く原因を探り出し、解決方法を提示できるかという力が重要です。
今回は、エラー解決までにどんなフローをたどると解決しやすいかを例を出しながらやっていきたいと思います。
(結構、メンターに向けてのメッセージである面も強いです。)

知っておいてほしいこと

こんなことを言うのは元も子もないですが、多種多様なエラーに対応するためには、それまでにどれだけエラーを見てきたか、その場数がすごく重要です。
OSで言えば、ファイルシステムがどうなっているのか・こういった拡張子はこういった用途である・このフォルダに入ってそうといったもの、
プラットフォーム面で言えばAPIそのものへの知識やライフサイクルなどの理解など、とにかく知っていればいるほど有利になります。
別にこれを読んだからと言ってすべてのパターンに対して解決マスターになれるとは言えませんが、考え方などを知ってもらえればいいかなと思っています。

エラーに出会う前

そもそも初めからエラーの出ないように開発するのが理想ですが、そんなものは何かを超越した人でないと無理なので、出来る限り気をつけながらコードを書きましょう。
例えば、 IDE上の表示を必ず見ておく というのも非常に重要です。
例えばこちら。
スクリーンショット 2016-12-13 20.18.08.png
if文の条件式の部分が何やら黄色くなっています。
カーソルを移動させてみると
スクリーンショット 2016-12-13 20.20.09.png
ご丁寧に 絶対にfalseになるよ! と言ってくれています。
他にも、文法に誤りがあれば基本赤線などが引かれます。
慣れていない人ほどIDEを使うべきですし、IDEが出してくれるこれらの警告に注意すべきです。
「こう書き換えろと言われるけど、そうするとこういうデメリットがあり、今回はそれが見合わないのでそのまま使う」という確固たる理由が出てから、無視するか警告を消すコードを挿入するようにしましょう。
「サジェストでSuppressっていうのがあって、それ選んだら消えた!」なんてのは以ての外です。
必ずメッセージを読みましょう。
(案外、IDEの警告を軽視している人は多いです)

エラーに出会ったら

はじめに

まず、どのようなエラーなのかを必ず残すようにしてください。特に、エラーログをしっかり見るのは解決の第一歩というか 必須行動 です。
有名所の言語であれば、基本的にどのようなエラーが出たか・どの場所で発生したかといった情報が出力されます。
(CのSIGSEGVとかは、急に死にますが、今回は一旦エラーログが取れた前提で話していきます。)

このJavaのエラーログ(スタックトレース)からはどのような情報が得られるでしょうか。
スクリーンショット 2016-12-13 20.35.38.png

NullPointerExceptionがMain4クラスのmethod3メソッドを実行している時、そのソースの18行目のところで発生した

これを導き出せれば合格です。
言語ごとにどのようなエラー形式で出されるかは言語によりけりですが、最低でも何というエラーが発生したのかこれは必ず把握できるようになってください。
どこでというのもほぼ必須級の情報ですが、言語によっては出ないところもあるので、その場合は前回の実行から何を変化させたかを意識しながら場所を絞り込んでください。

エラー名が分かったら

エラーの名前がわかったら、次はそのエラーが どのような時に発生するか を見定めてください。
例のものであれば nullな変数に対してメンバ変数の読み書きや何かしらのメソッドを呼ぼうとした といった感じです。

わからなければ、その名前をGoogleの検索フォームにぶち込んで、そのまま調べてください

私も初めて見るエラーはまだまだ多くあります。
分からずに放置してしまったり、投げ出したりするくらいなら、調べたほうが断然自分のためになります。

エラーをより細かく見る

上の例の例外にはありませんでしたが、エラーの種類の他に、エラーメッセージが合わせて出力される場合があります。

java.lang.String cannot cast to java.lang.Integer

もちろん基本英語です。
しかし、エラーメッセージは基本的に簡潔な文章で書かれている場合が多いです。
「やべぇ、英語だ」とは思わず、その意味を訳してみてください。
なんなら、このメッセージごとGoogleに放り投げてもいいくらいです。

解決策を考える

得られた情報から、何が原因なのかを考え、それをコードに反映させます。
とはいえ、初心者にとってこの行為は逆上がりを知らない状態で鉄棒の前に立たされるも同然です。
ここまで来るとGoogle先生は使いにくくなってしまうので、 誰かに聞きましょう
もちろん、今までの部分でも誰かに聞くことは悪いことではありません。
少なくとも、私は教えますし、Life is Tech !内部に拒む人はいないでしょう。
別の団体でも、そんな冷たい人はいないと信じたいです。

しかし、一つだけ徹底してほしいことがあります。

必ず、どうやって解決させたのかを聞いてください

誰かに聞いて解決してもらったのであれば、必ず 何がダメだったのか・どうしたら良かったのか この2点は必ず聞いてください。
そして、今後同じエラーに遭遇した時に自力でエラーに対処できるように、知識として吸収してください。
トラブルシューティングは自分の知識量との戦いです。

言いたかったこと

私は黒ポロメンターであるがゆえ、Life is Tech !内ではメンターメンバーどちらからも多くのエラーに関する質問を受けます。
初歩的なバグから、プラットフォームの基本動作を知らないといけないもの、複雑になってしまったエラーなど、数多くのエラーが寄せられますが、どれであってもはじめは分からないものがあって当然です。私も初めて見るエラーなんてまだまだたくさんあります。
解決に対する知識が多くなればなるほど、初見のエラーでも感づくようになってきます。
知識は得るものであり、他人からどんどん吸収していくものです。
質問しまくって、自分の知識として身につけていってください。