技術書の写経ができない

どういう勉強の仕方が良いか、悩んでいる。
この辺
http://d.hatena.ne.jp/meganii/20110221/1298292184
を見て、技術書のサンプルコードを打ち込んで動かすこと、いわゆる「写経」が大事かと思い、しばらく実践してみた。
しかし、

技術書の「写経」の方法。

1.ローカルで使える SCM を用意

2.「ほんたった」などで対象の本を固定

3.ひたすらサンプルコードを写して実行

4.実行するたびにコミット(コミットログにページ番号を含める)

5.疑問点があったらコミットログや本に書き込む

6.章ごとにタグを打つ

がどうしても継続できない。
技術書のサンプルコードにあるような、fooとかbarとか、自分の問題と直結しないプログラムを書くことが、どうしても続けられないのだ。(ましてSCMを使うなんて…という感じだ。)
元々好きで読んでいるわけだし、本文やサンプルコードを「読む」のは非常に興味をそそれらて面白いのだけれども、サンプルコードを打ち込むとなるとそうはいかない。
どうも義務感というか、「書かなきゃ」みたいに思ってしまって、嫌々やるから時間がかかるし、時間がかかるうちにモチベーションが下がってしまって、途中で投げ出してしまう。
でもその捨てた部分に良いTIPSが書いてあったりして、ひょんなことで本を開いたとき気付いて、「ああすればよかった」なんて後悔したりする。
途中で「写経」することによって読みが中断され、「なんだったっけ？」みたいになるのもイマイチだ。
こうなると、「写経」ありきで勉強するのは、自分には合ってないんじゃないかと思えてきた。
(多分読むスピードや、プログラムを書いて理解するスピードが遅いのもあると思う。)
次みたいな感じじゃないと、自分は続かないかも。

1.読みたい本は原則として手を動かさずに最後まで読む

どうしても「書きたい」という衝動にかられたときだけコードを打ち込む。
読者がコードを打ち込みながら読む前提で書かれた本であっても、気が向かなかったら書かない。
要は、読むスピード感と、そこから生まれる「知りたい」というモチベーションを大事にする。
そういう意味では、前に書いたことと矛盾するようではあるが、興味が湧かない部分は思い切って読み飛ばしたり、読みたいところから読む、とかもありかもしれない。

2.その本のノウハウを使って自分が欲しいプログラムを書く

やはり本を読むだけだと生きた知識にはならないと思うので、自分で使う前提で、どんな小さいツールでもいいから、一本書き上げる。
当然ながら、必要だと感じたり、疑問を感じたときは本を読み返す。
(実際にアウトプットを出すには、Webで調べたり、同じような課題がありそうなOSSのソースを読んだり、人に聞いたりとかも必要だろうが。)
ただし、人に見てもらうという意識は大事だと思うので、できればソースを公開して、GitHubなんかに上げた上でTwitterなんかに流すのが良いのかも。


本来、2.の前提として1.があるのが望ましいのだろう。
事実、仕事ではそうやって勉強とアウトプットを繰り返してきた。
しかし、自分が面白いと思ったのであれば、1.の上に2.があってもいいと思う。
2.は自分が作りたいと思うものなら何でもいいんじゃないだろうか。
例えばブログエンジンとかでも、自分にとってすれば得るものは沢山あると思う。
いずれにせよ、何も考えずに「写経」するのはもう止めようと思う。


古い記事だけど、この辺の方法論に近いのかな。こんなふうにちょっと加減な(失礼)方が、自分にはしっくり来るかも。
http://jibun.atmarkit.co.jp/lskill01/rensai/study/study001.html
中でも、翻訳プロジェクトに手を挙げるのはかなりありだ。