本を読んだらすぐパソコンを開こう

この記事は約 3 分で読めます。

読んだだけで満足していませんか

プログラミングの本を 1 章読み終えて、「なるほど、わかった」と思って本を閉じる。次の日、同じ内容を思い出そうとしても、ほとんど覚えていない。

これは記憶力の問題ではありません。本を見ながら読んでいる間は、手順の順番も変数の名前も、本の側が覚えてくれています。自分が思い出せている状態と、本に思い出させてもらっている状態は、読んでいる最中には区別がつきません。区別がつく場所はひとつだけで、本を閉じてエディタに向かった瞬間です。

だから、読み終わってからパソコンを開くのではなく、読んでいる途中で開きます。開くのが早いほど、「どこがわからなかったか」を自分がまだ覚えているうちに確かめられます。

なぜ読むだけでは足りないのか

プログラミングは体で覚えるもの

自転車の乗り方を本で読んでも、実際に乗らなければ乗れるようになりません。プログラミングも同じです。コードを自分の手で打って、動かして、エラーを直して。この体験を通じて初めて身につきます。

「わかった気」と「できる」は違う

本を読んで「わかった」と思っても、いざ自分で書こうとすると手が止まります。止まる場所は、たいてい本文に書かれていなかった部分です。ファイルをどこに置くのか、どの順番で実行するのか、前の章で作ったものがまだ残っている前提なのか。本は説明したいことを説明しているので、その周りの当たり前は省かれます。手を動かすと、その省かれた部分だけが残ります。

読んだ直後にやること

本が想定している環境を確かめる

打ち始める前に、本の前書きか最初の章にある環境の説明を見ておきます。使っている言語やツールのバージョンが書かれているはずです。ここが自分のパソコンと違うと、本の通りに打ったのに動かない、という止まり方をします。

このときのエラーは打ち間違いのエラーとは別物で、いくら読み直しても自分のミスが見つかりません。原因が自分の外にあると先にわかっていれば、同じ画面で悩み続けずに済みます。バージョンをそろえるのか、その本の新しい版に替えるのか、違いを調べながら進めるのか。最初に決めておきましょう。

本のコードをそのまま打つ

入門書に載っているコードは、コピー & ペーストではなく自分の手で打ちましょう。打ち間違えてエラーが出ますが、そのエラーを直す往復が、本文を読んでいるだけでは起きない部分です。

少しだけ変えてみる

本のコードをそのまま動かしたら、次は少しだけ変えてみましょう。数字を変える、文字を変える、条件を変える。「こう変えたらどうなるだろう」と試すことで、コードの意味が体感的にわかります。

エラーを怖がらない

入門書のサンプルを打ち間違えて、パソコンが壊れることはまず起きません。エラーメッセージは、どのファイルの何行目で何が起きたかを書いてくれています。長くて読み飛ばしたくなりますが、たいていは最初の 1 行と、自分が書いたファイルの名前が出ている行だけで足ります。

例外は、本文の説明ではなく環境を整える節に出てくる、ファイルを消したり設定を書き換えたりする種類の操作です。ここだけは打ち込む前に一度読み返してください。

読む単位を章より小さくする

本を 10 分読む → パソコンで 10 分試す → また本を 10 分読む。時間の長さは目安で、大事なのは切り替える間隔を章より短く取ることです。

1 章まるごと読んでから開くと、動かない箇所が出たときに、原因になりそうな場所が章の全部になります。数ページごとに試していれば、直前に読んだところだけを見直せば済みます。切り替えが面倒に感じるときは、本とエディタを開いたまま並べておきましょう。開き直す手間がなくなる分だけ、回数が増えます。

関連記事

• 本で読んだことを自分のコードに 1 つだけ取り入れる
• 本に出てくるサンプルコードは動かしてみよう

まとめ

プログラミングの本は、読み終わってから開くのではなく、読んでいる途中で開きます。本のコードを自分の手で打ち、少し変えて試し、エラーを直す。区切りを章より小さくしておけば、つまずいた場所と直前に読んだ場所が近いところにとどまります。読んだだけでは見えなかった「本が省いた部分」が、そこで初めて出てきます。