勉強法について

Question

(このサイトに限った話ではありませんが) 初心者にありがちな質問のパターンってありますね。

1. エラーメッセージを読まない。見慣れない英語の文章がダダーッと出てきた時点でパニックになってしまう。
2. そのものズバリの解決策にしか関心がない。問題の原因を掘り下げない。
3. 逆に、目の前のことがすみずみまで理解できないと、こわくて先に進めない。わからない部分が少しでもあると、自分には向いていないんじゃないか...と自信喪失する。

個人的には、以下のアドバイスを贈りたくなるのですが、回答者のみなさんも、それぞれに経験に裏打ちされたアドバイスを持っているのではないかと思います。それを紹介していただけませんか？

1. エラーメッセージはよく読むこと。見慣れないメッセージであれば、なおのこと、よくよく読む。辞書を引くくらいしても良い。エラーメッセージは情報の宝庫であります。
2. 問題との出会いは学習の好機。問題の原因を掘り下げて、原因をしっかり学びましょう。そして、原因がわかったら「感動」しましょう。そしてその感動を周囲に伝えてわかち合いましょう。
3. その時点で関心がわかないこと、よくわからないことは適当なところで打ち切って先に進みましょう。一周まわって帰ってきたときにわかることって、非常に多いです。何周も何周もまわって、ようやくわかることだって少なくないです。(論語に曰く「学びて時にこれを習う。またよろこばしからずや」)
4. ある程度経験を積んで、その分野への関心が高まったら、その分野における基礎的な理論を学びましょう。古典的な本、詳細な本を読む好機です。基礎は入門とは違うので、いきなり基礎からは入れないもの。経験を積んだときこそ、基礎に目を向けるべきです。

Answer 1

自分が後輩たちに教える場合にやっている事です。

エラーやわからない事が発生し質問されたら、まず答え(解決策)を教えてしまいます。
後輩のためにならないと思うかもしれませんが、
まず教えてから、「なぜこれで解決するのか」を調べさせてます。
その後、同じような問題が起きたときには、「それはこの前教えたやつをちょっと応用すればできるよ」というようなアドバイス(ヒント)をだします。

例外などがキャッチされて根本の原因がわからなくなった時、
質問者様の言う通り、「見慣れない英語の文章がダダーッと出てきた時点でパニック」になっているところで、
一緒にエラーを追ってあげる。
で、根本の例外を見つけたら、「あ、これこの前教えてもらったやつですね！」と、
進研ゼミの漫画みたいな感じになります(笑)

最初に100を教えて、次は50教えて、次は25教えて、・・・と徐々に教えることを減らしていっています。

参考になるかわかりませんが、これが自分の教え方です。

※
面白い質問ですね^^
他の方の教え方が聞けてとても勉強になります！

Comments

[chokojori]

おもしろい方法ですね。ちょっと目から鱗かも。どうしても正解をすぐに教えてはいけない...って思ってしまいがちです、自分は。

Answer 2

初心者が最もはまりがちな罠の根本は、やりたいことを分解できないことだと思っています。

例えば、「○○という条件の時に終了しなさい。」というと、

1. ○○ の時
2. 終了する

の２つに分解できない人が意外と多いのです。（ちょっと例が簡単すぎますが）

これはベテランと思う人の中にも、日頃の業務で触れていることだとできるのに、新しいことだと分解できない人が時々います。

プログラミングでは「処理を一つ一つに分解する、一つ一つ解決する」ということが重要です。
プログラムが思った通りに動くかは、半分以上はプログラミングスキルと関係ありません。論理的にやりたいことをパーツに分解できるかどうかです。言語もプログラミング言語である必要性すらありません。日本語で十分です。
どういう時に、何をするのか、これを細かく、自分の理解できる単位までプログラムの世界では分解していいんです。それをせずに大きい単位で物事を解決しようとするので、１～３すべての罠にはまってしまうのではないでしょうか。

この感性を養うことに限って言えば、フローチャートを使ってみることも良い勉強方法だと思っています。
勉強する時に、まずやりたいことをしっかり考える、図や口で処理を説明できるようになったら、そのやりたいことにそってコーディングをする。エラーが出たら、そのエラーがでたのは何の処理をやりたいところだったのか対応付けをしっかりすることで、エラーが「なんかエラーがでた」から、具体的な情報として扱えるようになっていくのではないでしょうか。

Comments

[chokojori]

なるほど。SICPの第1章でも、そのことが書かれていますね。

http://sicp.iijlab.net/fulltext/x110.html
強力なプログラム言語は, 計算機に仕事のやり方を指示する手段以上のものである. 言語はプロセスに関する考えをまとめる枠組としても役立つ. 言語について語る時, 単純な概念を統合して複雑な概念を構成するのに言語が用意している手段に特に注意しよう. これを達成するため, 強力な言語には三つの仕掛けがある.

• 基本式 言語が関る最も単純なものを表す.
• 組合せ法 より単純なものから合成物を作る.
• 抽象化法 合成物に名をつけ, 単一のものとして扱う.
プログラムする時, 二つの要素: 手続きと データを扱う. (それらが実はそれ程違わないことはやがて分る.) 早くいえば, データは処理したい「もの」であり, 手続きはデータの処理法の記述である. 強力なプログラム言語は基本的データと基本的手続きが記述出来, 手続きとデータを組み合せたり抽象化したりする手段を持たなければならない.

---
このことはシンプルだが強力なフレームワークなので、われわれは徹底して訓練する必要がありますね。

Answer 3

やっぱりはじめのうちは、IDEの使い方もよくわからないから、こんなエラーがでたんですけどとしか聞けないですよね。

自分が慣れてきてやるようになったのは、

デバックエリアを使う
エラーメッセージでググる
怪しいところでブレークを仕掛ける

メモにわかっているところ、わかっていないところを全て書き出す

ですね。

意外とわかっているつもりになっていることって多いので、整理して実はわかっていなかったと把握することが大切だと思います。それがわかれば、解決法を立てられるので。

Comments

[chokojori]

なるほど、

> メモにわかっているところ、わかっていないところを全て書き出す

これはいいですね。

まあ、何がわかっているか、わかっていないかすら、わからない...と言って、固まってしまう初心者は多そうですが。

個人的には、IDEで入門するなら、Visual Studioあたりかなあという気がします。
(Eclipseあたりだと、バージョンとかプラグインの問題で、混乱するので。全部入りになっているVisual Studioが固いかな、と。)

Answer 4

エラーメッセージでいえば
「エラーメッセージでググれ。まずはそこからだ。」
というのもあるかと。
いまは Web 検索があるので、本だけの時代よりもかなりラクになったはず。
ただ、その次の段階（原因の追及）へ移れない要因も Web 検索だろうと思われますので、そこをどうすればいいかは難しいです。

Comments

[chokojori]

そうですね。今、目の前にある課題の答えだけ出して、その本質へ関心が向かない...という傾向が若い人にある、という指摘をあちこちで目にします。(本当なのかどうかはわかりません。)

Answer 5

こんにちは
私も最近になってやっとまたプログラミングを覚えなおしています。
私の場合はあれもこれもとやってしまうことがあったので
今は比較的簡単そうなテトリスのクローンゲーム（コピーゲーム？）を
プログラミングして覚えなおしている最中です。
ゲームに限らず簡単そうなソフトを再現から始める方法も個人的にはありかと思います。

Comments

[chokojori]

なるほど、そうですね。
私の場合、UNIX流のパイプコマンドの有用さを学んだことが、プログラミングに開眼するきっかけになったように思います。特定の目的に特化した小さなソフトウェアの組み合わせで大きな仕事をする。特定の目的に特化した小さなソフトウェアは、小さいがゆえに設計しやすく、実装しやすく、テストしやすく、バグが混入しにくいので、良いわけですね。

ブライアン・カーニハンとP・J・プローガーの「ソフトウェア作法」がこの分野の古典ですね。
(私は「DOSを256倍使う本」シリーズで気付きを得て、その後、「ソフトウェア作法」に出会って、これが原典だったのか...となりました。)

Answer 6

こんにちは。

私も、まだまだ初心者ですが、普段から心がけなきゃいけないと思っていることがあります。

自分で1~10までコードを書くのはなかなか難しいので、いろいろなサイトからコピペして動かしてみるということをやっています。

このようなことをした時に、そのサイトのURLなり、連絡先なりをしっかりメモしていればなということが多々有ります。

2週間後の自分は他人

と言ったりしますが、人のサイトからコピってきたものならなおのこと2週間後の自分が理解できないコードであったりします。

また、どこかにupするときはライセンス等を記述しなくてはいけない場合もあり、メモしていない場合は、結局お蔵入りになったりもします。

まぁ、なんといいますか、まとめると未来の自分のためになるような、蓄えを作って欲しいという感じになりますかね。

Comments

[chokojori]

> 自分で1~10までコードを書くのはなかなか難しいので、いろいろなサイトからコピペして動かしてみるということをやっています。

おー。

自分も、ネット上にあるコードを参考までに使ってみることはありますが、それはあくまでも問題を理解するための練習でありまして、実際の製品コードは自分で1から10まで書きます。書けるようになるために練習するわけです。

実際の製品コードに、自分でもなぜ動いているかわかっていないコードを混ぜていたらダメだと思います。

[chokojori]

また、私の場合ですが、サンプルコードをコピー＆ペーストはしません。

手で入力します。手で入力することによって、皮膚感覚として理解すると言いますか、精読することができると感じています。

手で入力しながら、自分なりのコーディングスタイルに修正するということも、よくやりますね。多少タイプミスなどして、すんなり動かないことによって、修正作業を通じて理解度が高まる印象です。