はじめに
僕はフィヨルドブートキャンプでメンターをやっています。
その一環として生徒さんが書いたRubyのコードをレビューすることもよくあります。
そんなとき「そこはこんなメソッドが使えますよ」「こう書いた方がシンプルですよ」みたいなコメントを入れると、「なんでそんなにたくさんメソッドを知ってるんですか？」「どうしたら豊富な知識を身につけられるんですか？」という返事が返ってくることがあります。
このエントリではその質問に対する回答をあれこれ書いてみようと思います。
【もくじ】
前提として
まず前提として、初心者の方から見ると僕は「伊藤さん、すげー」ってなると思いますが、そういった「この人、すげー！」という評価は非常に相対的なものです。
僕だって「この人、すげー！それに比べたら僕なんて・・・」と思うことはたくさんあります。
つまり、僕は自分自身をすごいと思っているかというと別にそんなことはないです（でもRuby歴半年の人よりは確実にRubyが書けると思っていますが！）、と言い訳した上で本編へ進みます。
仕事で毎日コードを書いてるから（コードを書いてる時間が長いから）
単純な話ですが、僕は毎日仕事でRubyのコード（主にRailsアプリケーション）を書いています。
仕事でRubyを使い始めてから8年が経ちました。
仮に年間240日、1日あたり5時間コードを書いたとすると、「5時間 x 240日 x 8年」で、9600時間コードを書いてきたことになります。
まあ、これだけコードを書けば曲がりなりにも「Rubyチョットデキル」なプログラマにはなれるのではないでしょうか。
・・・みたいな話をしても、初心者の方は絶望してしまうと思うので、もう少し「初心者でもなんとかできる方法」を僕自身の経験から話しますね😅
とことんリファクタリングする
「徹底的にリファクタリングする」という精神でコードを書くと、いろんな便利メソッドや便利な言語機能を習得しやすくなります。
僕は昔からこんな感じでコードを書いています。
- まず直感でコードを書く（この時点では汚くても良い。動きさえすればOK）
- テストコードも一緒に書く（この時点でいったんgitにコミット）
- もっと短く書ける方法はないか、もっとスマートに書ける方法はないかと自問しながら公式ドキュメントを読みまくって使えそうなメソッドを探し、リファクタリングする
具体的には以下のようなポイントに気を付けながらリファクタリングします。
- ローカル変数を無くす
- 条件分岐やループのネストは1段までにする
- ブロックはなるべくネストさせない
# こんなふうにブロックがネストするのはNG text.split(' ').each do |word| word.each_char do |c| # ... end end
- 短くシンプルに書きつつ、可読性も重視する。短さと可読性を天秤に掛けなければならないときは可読性を取る
上のようなポイントに気を付けながらリファクタリングしていくと、多くの場合、メソッドチェーンが最適解になることが多いです。
具体例を挙げるとこんな感じですね。
# リファクタリング前 def to_ints(hex) r = hex[1..2] g = hex[3..4] b = hex[5..6] ints = [] [r, g, b].each do |s| ints << s.hex end ints end
# リファクタリング後 def to_ints(hex) hex.scan(/\w\w/).map(&:hex) end
ちなみに上のコードは拙著「プロを目指す人のためのRuby入門」に出てくるサンプルコードです。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者:伊藤 淳一
- 発売日: 2017/11/25
- メディア: 大型本
こういうコードの書き方を繰り返していると、だんだん「カッコいいコードの書き方」が自分の道具箱に増えていきます。
（やりすぎると中二病っぽいコードができあがりますが、それは誰もが一度はかかる「はしか」みたいなもの、ということで・・・w）
リファクタリングに欠かせない、テストコードとgit
また、リファクタリングするときは「テストコードがあること」と「リファクタリングが終わるたびにgitにコミットすること」も重要です。
テストコードはリファクタリングによってプログラムが壊れていないかどうかをチェックするために使います。
テストコードがあれば「コードを変更！テスト実行！パスした！よし、次！」という勢いをずっとキープできます。
テストコードがないと、「コードを変更！プログラム実行！えーと、ここがこうで、こっちがこうだから・・・たぶん大丈夫かな。じゃあ、次」みたいなテンポになるので、リファクタリングの効率が悪くなります。（さらに、テストコードがないとバグを作り込んでしまう可能性も・・・）
リファクタリングの仕方がまずくてテストが落ちるときは、いったんコードを変更前の状態に戻したい、と思うことがあるかもしれません。
そんなとき、gitで「以前正しく動いてコード」にロールバックできれば、プログラムが壊れてしまっても怖くありません。
コミットはドラクエのセーブデータのようなものです。（と言っても若い人たちはわからないか）「何かあったらここに戻りたい」というタイミング（＝リファクタリングが1つ進んだ時点）で、gitにコミットする癖を付けましょう。
コードレビューしてもらう / コードレビューする
コードレビューもその言語に関する知識を増やすのにたいへん有効です。
コードレビューは「自分がされる側」になるときと、「自分がする側」になるときの2パターンがありますが、どちらも勉強になります。
特に相手のスキルが高ければ高いほど、もっといい書き方を教えてもらったり、自分がレビューするときに「こんなメソッド知らなかった！」という新しい発見があったりすることが多くなります。
モブプロやペアプロをする
モブプロやペアプロにもコードレビューと同じような効果があります。
コードレビューはたいてい非同期にコミュニケーションになりますが、モブプロやペアプロは同期的なコミュニケーションです。
すなわち、その場でリアルタイムにお互いの知見を交換し合うことになります。
コードレビューと同じく、スキルの高いメンバーがいると、より有益な知見を得ることができるはずです。
人に教える
他の人にコードの書き方を教えることもまた、自分の勉強になります。
中途半端な知識だと相手にうまく教えられないので、教える側も必死で勉強することになります。
「自分は初心者だから教えられることなんて何もない」と考えずに、「教えることで自分も成長するんだ！」という気持ちで積極的に人助けする方が、良い結果が得られるはずです。
ちなみに「人に教える」というのは直接顔を合わせながら教えるというのはもちろん、Teratailやスタックオーバーフローのような技術系Q＆Aサイトで質問に答えることも、人に教えることに含まれます。
コラム：自分で自分好みの勉強会を主催してみる
「コードレビューしてもらうにも、モブプロやペアプロをやるにも、人に教えるにも、自分は今仕事でコード書いてるわけじゃないから、そんな機会自体がないんです😣」という方も多いと思います。
そんな人は近くでそういったことをやってる勉強会がないかチェックしてみてください。
え？「勉強会もやってないよ！」って？
じゃあ、勉強会を自分で主催してみましょう！
最近はちょっと活動が少なくなってしまいましたが、僕も西脇.rb＆神戸.rb（旧名 西脇.rb＆東灘.rb）というRubyコミュニティを主催して、自分が面白そうと思ったテーマで勉強会を開いていました。
具体例をいくつか挙げるとこんな感じです。
- 西脇.rb & 東灘.rb ペアプログラミング In Action - 西脇.rb ＆ 神戸.rb | Doorkeeper
- 西脇.rb & 東灘.rb Ruby リファクタリング Dojo - 西脇.rb ＆ 神戸.rb | Doorkeeper
- Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～ - 西脇.rb ＆ 神戸.rb | Doorkeeper
最近は新型コロナの影響でリアルに人が集まる勉強会は開催しにくくなってしまいましたが、オンラインイベントとして勉強会を開催することも可能です。
何十人も集まるような大きな勉強会を開く必要はありません。
最初は参加者が2〜3人でもOKです。
「二人集まれば勉強会」を合い言葉に、小さな勉強会を主催してみましょう😉
情報をインプットする
単純にRubyに関する情報を書籍やネットから収集することももちろん有効です。
また、これは自分一人でもできます。
（できれば中級者以上の）技術書を読む
「いろんなメソッドの使い方を知る」「いろんな言語機能に精通する」という目的であれば、初心者向けの本よりも以下のような中級者向けの本を読んだ方が良いと思います。
- 作者:Peter J.Jones
- 発売日: 2015/01/19
- メディア: Kindle版
手前味噌ですが、僕が書いた「プロを目指す人のためのRuby入門」でも中級者向けのテクニックを紹介したりしています。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus
- 作者:伊藤 淳一
- 発売日: 2017/11/25
- メディア: Kindle版
Rails関連であれば最近改訂版が発売された「パーフェクトRuby on Rails」が良いかもしれません。
技術書ではありませんが、僕が以前Qiitaに書いたこちらの記事でもRubyやRailsの便利メソッドをたくさん紹介しています。
qiita.com
Ruby Weeklyを読む
Rubyに関する技術情報を毎週発信してくれるRuby Weeklyという無料のメルマガがあります。
英語のメルマガですが、英語の勉強を兼ねて購読してみると良いと思います。
週刊Railsウォッチを読む
週刊Railsウォッチも毎週RailsやRubyに関するお役立ち情報を提供してくれます。
こちらは日本語で読めるので、日本人でもハードルが低いはずです。
Ruby/Rails界隈のスーパーエンジニアをTwitterでフォローする
Ruby/Rails界隈のスーパーエンジニアをフォローするのもやはり有益な情報を得るのに役立ちます。
少し前の記事ですが、以下のブログ記事は今でも十分有効なアカウントリストだと思います！
あと、スーパーエンジニアではないですが、ときどきRubyやRailsに関するお役立ち情報を発信しているアカウントはこちらです👇
情報をアウトプットする（丸写しではなく自分の言葉で）
自分が学んだことをブログやQiitaにまとめると、記憶の定着に役立ちます。
たとえば、僕の場合は「RubyのTimeとDateTimeの違いがよくわからない！調べてみよう」と思い、あれこれ調べまくって、わかったことをQiitaに書きました。
そのときに書いた記事がこちらです。
この記事を書くことで、僕はTimeとDateTimeの違いを完全に理解しました。
（というか、このとき以来、DateTimeクラスを使うことはなくなりました！）
他にも僕は毎年Rubyのバージョンが上がるたびに新機能のまとめ記事を書いていますが、これもRubyに新しく追加されたメソッドなどを覚えるのにとても役立っています。
でも、丸写しはダメ！🙅🏻♀️
ただし、このときに注意したいのが「本やネットの記事を丸写ししない」ということです。
著作権上、無断転載にあたるから良くない、というのももちろんそうなのですが、それ以上に「学習」という観点においては「右から左へ書き写すだけ」ではその技術をちゃんと理解できていない恐れがあるのが一番の問題です。
逆に「○○って何ですか？」と突然聞かれたときに、ネットを見ずに自分の言葉でちゃんと説明できるのであれば、その技術をきちんと理解できていることになります。
このあたりの話はこちらのブログ記事に詳しく書いています。
blog.jnito.com
丸写しになるのを避けるために、「もし、タイムマシンに乗って、その技術を知らなかった頃の自分自身に教えるなら、どうやって説明するか？」を想像しながらアウトプットすると、きっと良いアウトプットになると思います。
qiita.com
本を書く or 翻訳する
これはなかなかハードルが高いと思いますが、本を一冊書いたり、海外の技術書を翻訳したりするのもめちゃくちゃ勉強になります。
僕は「Everyday Rails - RSpecによるRailsテスト入門」という本を翻訳することで、RSpecの使い方をマスターしましたし、「プロを目指す人のためのRuby入門」という本を執筆することで、Rubyの細かい言語仕様を理解することができました。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者:伊藤 淳一
- 発売日: 2017/11/25
- メディア: 大型本
「伊藤さんってなんでそんなにRubyやRSpecに詳しいんですか？」の答えのひとつがここにあることは間違いありません。
登壇する
本の執筆はハードルが高すぎるかもしれませんが、勉強会で登壇するのは本の執筆に比べればまだハードルが低いと思います。
Qiitaやブログを書くときは「誰が見てるかわからんし、反応もほとんどないから適当でいいや」となるかもしれませんが、登壇の場合はそうはいきません。
その場で自分の発表内容を評価されるので、おのずと「ウソを書かないように気を付けなきゃ」「ちゃんとわかりやすく説明しなきゃ」という意識が働きます。
そうやって発表内容をブラッシュアップする過程で、対象の技術に関する知識をより深めることができます。
「いきなり30分近い登壇をこなすのは怖くて無理！😣」という人は、持ち時間が5分程度のライトニングトーク（いわゆるLT）からトライしてみると良いかもしれません。
その他：特定の分野のスペシャリストを目指す
僕が「RubyやRSpecについて詳しい人」と思われているのは、「その分野に関するスペシャリストだから」という見方もできます。
つまり、昔も今もそこにフォーカスを絞ってるので、「RubyやRSpecをよく知ってる人」という地位をキープできています。
それ以外の分野、たとえばJavaScriptやDockerといった分野に関しては、「プログラマという仕事上、ある程度は知っているし、経験もあるけど、RubyやRSpecほど詳しくない。むしろ、知らないこともたくさんある」という状態です。
もちろん、JSやDockerについても詳しく知っておいて損になることはないのですが、次から次に新しい技術が登場してどんどん複雑化するこの業界において、すべての技術に精通した完璧超人を目指すというのはほぼ不可能です。
であれば、自分の得意な分野を絞り込んで「その道のスペシャリスト」を目指した方が、エンジニアとしての生存確率を上げられるかもしれません。
・・・と、偉そうなことを書きましたが、僕がRubyやRSpecのスペシャリストであるのは、「RubyやRSpecが好きだったから」という単純な理由です。
好きなことだといくら時間をつぎ込んでも苦痛にならないので、おのずとスペシャリストになれます。
このあたりの話はこちらのブログ記事に以前書いています。
まとめ：3年ぐらいがんばれば大丈夫
というわけで、今回のエントリでは「伊藤さんってなんでそんなにRubyについて物知りなの？」というRuby初心者さんの質問にあれこれ答えてみました。
ただ、当然ですが、僕も最初からRubyやRSpecをすらすら書けていたわけではありません。
僕だって初心者の時代がありましたし、その頃は四苦八苦しながらコードを書いていました。
冒頭にも書いたように、僕が物知りになったのは、単純に「8年間ずっと仕事でRubyのコードを書いてきたから」というそれだけの理由かもしれません。
「8年？そんなにかかるの！？」と思われるかもしれませんが、必ずしも8年かかるわけではありません。
そうですねえ、僕の感覚でいうと、「3年ぐらい」です。
初心者の人でも3年ぐらい一生懸命勉強してたくさんコードを読み書きすれば、かなり自信が付いてくると思います。
「3年ぐらいがんばれば大丈夫」という話は、以前書いた下のブログ記事にも書いています。
blog.jnito.com
とはいえ、3年と言われても「長いなあ。大変そうだなあ」と感じる人はたくさんいるでしょう。
その3年間を短く感じられるようにコツがあります。
それは「技術を楽しむこと」「技術を好きになること」です。
好きなことや楽しいことをやっているとあっという間に時間が過ぎていきます。
ふと気づけば「え、もう3年？」という状態になっていて、そのときにはそれなりのスキルが身に付いているはずです。
でも、「プログラミングってなんか楽しくないな」「難しいことばかりで心が折れそうだな」と思ってる人も、「自分には適性がないんだ」と諦めないでください。
もしかするとそれはフロー理論でいうところの「不安状態」にずっと陥っているせいかもしれません。
「不安状態」にいる人は、ちょっと無理して頑張りすぎている可能性があるので、もう少し気を楽にして、自分に合ったレベルまで難易度を下げてみると、またプログラミングが楽しくなってくるはずです。
高い目標を掲げることも大事ですが、すぐに心が折れてしまうような無理な目標を設定するのはやめましょう。
それよりも自分に合った目標をコツコツこなしていく方が、絶対成長できます。
なんだかんだいっぱい書いてしまいましたが、以上が「伊藤さんってなんでそんなにRubyについて物知りなの？」という質問への回答でした！
2021.1.10追記：「3年やればうまくなる」という話が本に書いてあった
自分の経験上、「3年ぐらいやれば何でもうまくなるはず」と思って上のような話を書きましたが、先日読んだ「世界一わかりやすい 教える技術」という本にほぼ同じ話が書いてありました。
料理にしても、スポーツにしても、語学にしても、ソロバンにしても、プレゼンにしても、ルービックキューブにしても、どんなことも、だいたい５０００時間をかけて練習すれば、熟達するということが明らかになっています。
５０００時間というのはどれくらいの時間かというと、１日５時間で毎日練習すると、３年間で５０００時間になります。もし、土曜日と日曜日は休みたいというのであれば、平日１日７時間練習すれば、３年間で５０００時間になります。
つまり、だいたい３年でうまくなれるということです。
向後 千春. 世界一わかりやすい 教える技術
僕の感覚だけじゃなく、世間的にも「3年」という数字はそれなりに根拠がある、ということですね。
- 作者:向後 千春
- 発売日: 2020/10/09
- メディア: Kindle版
あわせて読みたい
5年前に浜松Ruby会議01で登壇したときのスライドです。
ここに書いてある話も、今回のエントリとほぼ同じ内容になってるんじゃないかと思います。
