Ruby のコードリーディング会に参加して1年経ちました

EC 事業部の akatsuura (@UVB_76) です。最近は AFTER SIX LEAGUE という企業対抗戦の Apex Legends 部門に参加していて、毎月他の企業の参加者と競っています。

ペパボではお昼休みに OSS コードリーディング会という GitHub で公開されているライブラリのコードを読みすすめる会が開かれています。私はこの会が始まった 2019 年から参加し続けています。気がついたら 50 回近くの開催となっていたのでこの機会に進め方やわかったことをここで共有します。

尚、現在の参加者は Ruby on Rails で開発を行っている人たちがほとんどで、コードリーディングの対象も gem 形式で公開されている Ruby のライブラリが中心になっています。記事の中には Ruby 固有の話も出てきますが、他の言語でも読み方自体については同じようなことができるのではないかと考えています。

進め方

週 1 回お昼ごろの 1 時間弱を使って Google Meet の通話に集まり、画面共有しながらモブプロのようにコードを読んでいます。 読んだ記録は社内でホストしている Scrapbox に記録しています。

どこまで読むかを決める

週 1 の短い時間でコードを全部読もうとすると時間がかかりすぎるので、コードを読み始める前にある程度読む場所を絞ります。例えば、最近読んだ Pry を例に上げると、 binding.pry を呼び出してから REPL の入力待ちになるところまでの処理に絞るなどです。

README.md を読む

読み始める際にはまず、そのリポジトリの README.md をざっくり読んで使い方をおさらいします。 自分たちが利用しているライブラリでも知らない機能やオプションがあり、学びになることが多くあります。

コードを読む

コードを読む際は GitHub のサイト上でリポジトリを探索したり、ローカルで Clone してきたリポジトリを VSCode Live Share で共有しながら読み進めています。また、最近 VSCode 風のエディタ画面でリポジトリを閲覧できる Web サービス が話題になっていましたが、こちらも VSCode を使い慣れた人にとっては便利だと思います。

メソッドを素早く探す

コードを読んでいると、言語やフレームワークのメソッドで使い方がわからないものが出てきます。言語のドキュメントを素早く検索する方法はいくつかありますが、私はブラウザで完結させたいと考えていて、そのために Google Chrome の検索エンジンの設定を調整しています。 既定の検索エンジンを設定する - パソコン - Google Chrome ヘルプ

例えば Ruby にはるりまサーチというリファレンスの検索サイトがありますが、以下のような設定を Chrome に追加することで、 Chrome のアドレスバーから検索が可能になります。

• 検索エンジン
  • るりまサーチ
• キーワード
  • rb
• URL
  • https://docs.ruby-lang.org/ja/search/query:%s/

Rails も Ruby on Rails API というリファレンスサイトがあります。こちらは Chrome の拡張 (Ruby on Rails API Search) があるのでそちらを利用すると良いでしょう。

実際に使ってデバッグする

メソッドの挙動がコードを読むだけではわからないときはテストコードを読んだり、実際にライブラリを使用するコードを書いて pry-byebug などのデバッガを使って確認します。

どんなコードを読んできたか

冒頭にも書きましたが、参加者は Ruby on Rails で開発を行っている人たちがほとんどでした。そのため、自分たちが Rails のアプリケーションを開発する中でよく使用するライブラリや Rails そのものを構成しているライブラリがコードリーディングの対象になりました。これまでに読んできたコードは以下のとおりです。

• rack/rack: A modular Ruby web server interface.
• sinatra/sinatra: Classy web-development dressed in a DSL (official / canonical repo)
• lostisland/faraday: Simple, but flexible HTTP client library, with support for multiple backends.
• fgrehm/letter_opener_web: A web interface for browsing Ruby on Rails sent emails
• rails/action_dispatch.rb at main · rails/rails
• fxn/zeitwerk: Efficient and thread-safe code loader for Ruby
• amatsuda/jb: A simple and fast JSON API template engine for Ruby on Rails
• pry/pry: A runtime developer console and IRB alternative with powerful introspection capabilities.

わかったこと、得られたこと

この会を続けて 1 年経ったところでふりかえりを行い、この会でわかったことや得られたことを参加者に列挙してもらいました。まとめると、以下のような良い影響があったようです。

コードリーディングそのものについて

• エディタやブラウザでコードを検索する速度があがった
• 見たことのない組み込みメソッドの存在を知れたり使い方を学んだ

ライブラリの設計について

• メソッドを適切に切り分けることで読みやすくできることがわかった
• 長くてもわかりやすい名前がつけられているケースがあることに気がついた
• 設定やオプションをどう引き回すと良いかの知識が得られた
  • 自分でライブラリを作るときの参考実装の種類が増えた

Ruby 言語について

• ブロックをとるメソッドの発火タイミングがわかった
  • yield を見ても動じなくなった
• メタプログラミング(メソッドの動的生成)を読むのに慣れた
  • NoMethodError に遭遇してから、メソッドを動的に生成している箇所にたどり着くまでの速度が上がった
• namespace がどう使われているのがわかった

その他

• 登壇のきっかけになった
  • RubyのOSSコードリーディング
• REPL の表示で使用されていた制御文字に興味が湧き出した

ゴールの見直し

初回の開催時にこの会を通じてどうなっていると良いか、以下のようなゴールをざっくりと初回の参加者で決めていました。

• 題材にした OSS の Issue を見て、どの辺を触れば直るのかがわかるようになる
  • マージされたPRを見て、おおよそわかるようになる
• OSS の規模感が掴めるようになりたい
  • 勉強会を進めていた結果、規模感を掴む力がつく
• 読まなくていいコードを読まない力がつく
  • 例えばメソッド名から何をしているのか推測する力
• 単純に Ruby の様々な書き方がわかるようになる

上記のふりかえりを見ると、 OSS (ライブラリ)の規模感、 Ruby の書き方、読まなくていいコードを読まない力については少しは満たせているように思いました。

これからどうするか

このままコードリーディングを続けてもよいのですが、もう一歩進展して以下のことにもチャレンジしていこうと思います。

• Ruby のライブラリの読み方はわかったので今度はコントリビュートしてみる
• Ruby 以外の他言語のライブラリを読む企画を立ち上げてみる