フレームワークから入ると、言語が抜ける
CMSを作っている会社にいたころ、製品のベースがRailsでした。仕事は管理画面やフロントの改修です。
コードは目の前にあります。動いてもいます。それなのに、何をしているのか読めませんでした。
フレームワークの側から入ると何が抜けるのか、なぜ言語の本を読み直したのか、そしてこの本で埋まった部分と埋まらなかった部分です。
読めない、の中身
最初は「経験が足りないから読めない」のだと思っていました。実際には、もっと具体的な詰まり方をしていました。
目の前の1行が、Railsが用意した仕組みなのか、Rubyの文法なのかが区別できない。
これが分からないと、次の一手が決まりません。
| その行が何か | 調べに行く先 |
|---|---|
| Railsの機能 | Railsのドキュメント、そのバージョンの仕様 |
| Rubyの文法 | 言語のリファレンス |
| 製品独自の実装 | 社内のコードと、書いた人 |
3つのどれかは分かるのに、どれなのかが分からない。結果として、調べ始める場所が決まりませんでした。
手が止まっていたのは、書き方が分からないときではありません。どこを調べればいいか分からないときでした。
検索の言葉すら決まらないので、当てずっぽうで探すことになります。
フレームワークから入ると、言語が抜ける
入り方が逆だった、というだけの話です。
ふつうは言語を覚えてからフレームワークに進みます。自分は製品の改修という入口から入ったので、Railsの決まりごとは仕事の中で覚えていきました。「こう書けば動く」は増えていきます。
ただ、その下にある言語そのものは通っていません。だから、Railsの型に当てはまらない行に出会った瞬間に読めなくなります。
フレームワークの作法だけでも、決められた形の改修はできます。できないのは、形から外れたときの判断です。
「動いているから正しい」以上のことが言えないまま進むことになります。
言語の本に戻った
そこで読んだのがこの本でした。Railsの本ではなく、Rubyそのものの入門書です。
文法を順番に追う構成なので、フレームワークの側から入って穴が空いている状態を埋めるのに向いていました。「ここはRubyの書き方だ」と分かるようになると、調べに行く先が決まります。それだけで手が止まる回数がはっきり減りました。
特に効いたのは、ブロックやシンボルのようなRubyでは当たり前だが、他の言語から来ると初見のものです。Railsのコードにはこれらが大量に出てきます。知らないまま読むと全部が「Railsの魔法」に見えます。
この本で埋まらなかったこと
当然ですが、Railsの作法はこの本には書いてありません。言語を埋めるための1冊と割り切る必要があります。
それと、他の言語をすでに書ける人にとっては、前半は既知の内容が続きます。飛ばしながら読んで、知らない書き方が出てきたところで止まるという読み方になりました。最初から順に読む本としては、少し長く感じるかもしれません。
たのしいRuby 第6版Informatics & IDEA
- 使っている理由
- CMSベンダーにいたとき、製品のベースが Rails だった。管理画面やフロントの改修に入るのに、Ruby そのものを知らないままでは手が出せなかった。
- 効いた点
- 文法を順に追える構成なので、フレームワークの側から入って言語を知らない状態を埋めるのに向いている。改修中に読んだコードの意味が分かるようになった。
- 合わなかった点
- Rails の本ではないので、Rails の作法はこれとは別に覚える必要がある。言語を埋めるための1冊と割り切るのがいい。
リンクは広告を含みます。
今回の学び
まず、入る順番は逆でもいいが、どこかで戻る必要があること。フレームワークから入るのは実務では珍しくありませんし、そのほうが早く戦力になります。ただ、戻らないままだと「形から外れた瞬間に止まる」状態が続きます。
次に、詰まりの正体を言葉にすると、対処が決まること。「読めない」のままでは何を勉強すればいいか分かりませんが、「言語かフレームワークかの区別がつかない」まで分解できれば、読むべき本は1冊に決まります。
そして、調べる場所が決まらないことが、いちばん時間を食うこと。答えを探す時間より、探す場所を決められない時間のほうが長かった。ここは知識の量ではなく、切り分けの問題でした。
