こんばんは！
ゆうです！
今回は
『プログラミングの勉強において
「理解した」とはどういう状態か』
についてお伝えします。
まず「理解した」を定義する
「理解した」という言葉を人はよく使います。
しかし、その「理解した」という言葉は
人によっても文脈によっても意味は様々になります。
例えばこの様な使い方をする人がよくいます。
- 一通り本を読んだので、Rubyの事を「理解した」
- RailsTutorialを使ってTwitterの劣化コピーを作ったので、Railsの事を「理解した」
この2つの「理解した」という言葉は、
一体何がどうなった状態を意味している
のかがわからないのではないでしょうか？
「理解した」という事をあまり深く考えずに
学習を進めてしまうと、
- 到達したかったはずの水準のスキルが身につかないまま時間だけが過ぎ去る
- 「自分は出来るんだ」という誰も幸せにならない根拠のない自信だけが醸成される
1から10まで説明出来るを
「理解した」とする
様々な解釈があると思いますが、
私は勉強した内容を真に「理解した」とする基準を、
学習した内容を1から10まで説明出来る
として設けています。
プログラムのコードの1行1行には
ちゃんと意味があります
(意味不明なコードも時々ありますが)。
説明出来ない個所があるとすれば
理解できていない個所がある
ということになります。
「理解した」と思っても、「説明できない箇所」は
必ず現れるといってもいいでしょう。
説明を通して自分の理解が曖昧な箇所が現れる度に、
新たに勉強するべき項目が浮き彫りになっていくのです。
似たような話として、達人プログラマという書籍
の中で紹介されている、ラバーダックデバッキング
という有名なデバッグの手法があります。
興味のある方は調べてみて下さい。
私が個人的に教えているエンジニアの方には
ほとんどの場合、1から10まで説明出来る事を
理解度の指標として明確に設定しています。
コードレビューの際に自分が書いたコードを
上から下まで全て説明し、一つでも説明出来ない
項目があれば、その部分は「理解した」とは
みなさず次のステップに進めなくしています。
そうやって
研修生が「理解した」という言葉の水準が
一定に保てるように工夫しています。
用語を正しく使って説明をする
説明をする時に重要な事は、
用語を正しく使う事です。
プログラミングの世界には、
沢山のその分野特有の用語があります。
用語とは特定の分野における抽象的な概念を
皆が統一して理解するために用意された具体的な
キーワードの事です。
用語の意味を理解することは、
その分野の重要な概念を理解することに繋がります。
逆に言えば、用語を正しく使って学んだ内容を
1から10まで説明する事は、
その用語の意味がわかっていないと
そもそも出来ません。
用語の理解を曖昧にしたまま放置していては
いつまでたってもスキルは向上しませんし、
こういう記事の対象者になってしまう
かもしれませんので気をつけてください。
3. 情報の信頼性を優先する
プログラミングの勉強を進めていくと
分からない事が沢山あるので調べて
その疑問を解決する作業が無数に発生します。
調べ物をする際に、どんな情報源を選択するかは
状況によってまちまちですが、
選択基準を大きく分けると
以下の2つのがあります。
- 欲しい情報に辿り着く速さ
- その情報の信頼性の高さ
そしてこの2つのうち、情報に辿り着く速さよりも
情報の信頼性の高さを優先するべきです。
wikipediaによると情報とは
文字・数字などの記号やシンボルの媒体によって伝達され、受け手において、状況に対する知識をもたらしたり、適切な判断を助けたりするもののこと。
という意味なので、状況に対して適切な判断や知識が得られるかは、
その情報がどれだけ信頼できる情報かにかかっているのです。
つまり、必要条件が情報の信頼性で、
情報に辿り着く速さはあくまで十分条件で
あることを忘れてはいけません。
誤学習によって発生するコストは、
学び直すだけではすまない
(重大なバグを生み出すなど)
事もあるので、肝に銘じましょう。
情報源の特性を活かして調査をする
調べ物をしたり学習を進める際には、
様々な情報源のメリット・デメリットを
活かしながら、それらを組み合わせて
学習することが大切になります。
以下にそれぞれの情報源のメリット・デメリットを
まとめました。見ての通り、とてつもなく当たり前です。
| 情報源 | メリット | デメリット | 用途 |
|---|---|---|---|
| 書籍 | 情報が体系的にまとまっていて、信頼性は高い | 学習時にはバージョンが古くなっていることが多い。環境によって差異があるケースがある。 | 体系的な情報をインプットする際に使う |
| ブログ | 抽象的な疑問に対して、素早く解決方針を絞り込むことができる | 断片的かつ個別な情報になりやすく、情報の信頼性が担保しにくい。環境によって差異があるケースがある。 | 問題解決の方針の絞り込みに使う |
| 公式リファレンス | 情報が必要十分かつ、信頼性が高い(場合が多い) | 調べたいことが明確にわかっていないと検索することが難しい | 解決方法の詳細や仕様の確認に使う |
| 手元にあるソースコードやバイナリ | 1次情報なので、ほぼ信頼出来る | 解決方針が決まらないとそもそも確かめようがない。初心者にはややハードルが高い。 | 最終的な確認に使う |
上にあげたメリット・デメリットを
整理した上で、私が日常的に勉強の際に
調べ物をする時の流れを紹介します。
- 書籍をベースに学習を進める
- 書籍で解決出来ない疑問が生まれた段階で、Googleでわからない事を調べる
- いくつかブログなどを見て問題の解決策になりそうな部分を特定する
- その解決策に該当する部分をリファレンスを読んで確かめる
- 手元で実行して確かに動作をするか確認する
調べる方法には唯一絶対の正解があるわけではなく、
状況によって必要な情報の信頼性を保証し、
なおかつ素早く調べる事ができるやり方を
構築していって下さい。
リファレンスの読み方を覚える
上述したように、調査をする上で信頼性を
担保するためにはリファレンスを読む
ということが必要不可欠になります。
しかし、初心者には英語で書かれていることや、
そもそも読み方がわからないということが、
とっつきにくいという印象を与えてしまいます。
そこで、簡単にリファレンスの読み方を説明していきます。
通常リファレンスを読む際には、
- ◯◯というメソッドの仕様を詳しく知りたい
- ◯◯という機能を提供しているクラス・メソッドを探したい
上記のような動機で利用することが多くなります。
そこでリファレンスに記述されている
メソッドの読み方を紹介しようと思います。
リファレンスに記述されているメソッドを読む際は、
以下の4つの注意点を押さえて読んでいくことで、
そのメソッドがどんなメソッドであるかを
理解する事が出来るようになります。
- レシーバーは何か？
- 引数は何か？
- 返り値は何か？
- 副作用はあるか？
基本的には上記のような点を押さえておけば
様々なメソッドを理解することが可能になります。
リファレンスの正しい読み方を理解することで、
信頼性の高い情報を調査するコストを
飛躍的に低減することができます。
わからない方は上司や先輩に聞いてみましょう。
以前やらせていただいたアンケートにて
質問が多かったので用語と
PHPやMySQLのリファレンスの具体的な読み方
をまとめた資料を配布します。
今回もサポートを行う予定ですので
このブログを読んでくださるあなただけ
さらにいうと
【限定10名】のプレゼントとします。
埋まり次第この記事も非公開にしようと
考えております。
それではこの辺で！
最後まで読んでいただき、ありがとうございました！