社内部活制度でgemのコードリーディング会を実施した話

前置き

こんにちは。株式会社Relicのyamashitaというものです。
弊社にはさまざまな部活動がありまして、ruby部、php部、aws部…音楽部、お金部、などなど。。
社員は自由に部活動を選択でき、そのテーマに興味のある仲間と交流しながら技術を高め合う事ができます💡

あ、最後の2つは技術の話ではなかったですね…。失礼しました。

ruby部について

私は参加してから1ヶ月ほどになります。

週に一度30分ほどの集まりが催され、rubyをテーマにしたお題について議論をするのがデフォルトです。
いまは3名のエンジニアが運営ですが、つよつよなruby大好き業務委託さんも、この勉強会に大いに貢献してくださっています。運営の皆さん、いつもありがとうございますｍｍ

トライしてみたこと

部活動の話とは別件なのですが、プロジェクト内で既存のテーブルの命名を見直す会をしていたときのこと、
メンターに「たまにはOSSのコードも読んでみるとよいょ」と言われてmastodonのスキーマをほいっと渡されました。
（データの持ち方に応じてどんな命名をしているか勉強になったので、お時間あったら読んでみてください。）
（完全なる余談: IPアドレスを扱っているテーブルの命名が個人的気になりポイント👀）

「たまにはGitLabのコードも読んでみるかあ。。」と
rubyを使った有名なOSSのコードを読んでみよう！と思ったのはこれが初めてではなく、それでも一人でやろうとするとちょっと億劫だなあという気持ちが勝ってしまう。。

今回はそういう気持ちをちょっとでも前向きにすべく、ruby部のみなさんにお付き合いいただくことにしました。
普段なかなか気にかけることのない、セッション周りの実装をしているgemを読んでみることにしました。

[request_store]
https://github.com/steveklabnik/request_store

よかったこと

• rubyだけではなく、言語をまたいでも変わらない技術の背景だったり、仕様を知ることが出来た。
• 読み解けないところは、強い人に質問して読み進めることが出来る。
• 質問する前に自分の解釈を表明することも出来た。（もちろん認識違いについては質問をその場ですることで、解消するように努める）
• テストコードをお題にしたので、gemの仕様が把握しやすかった気がする。

アジェンダ

だいたい45分程度になりましたが、ざっと以下のような流れです。

• gemのREADMEを読んで、このgemが開発されるに至った背景を知る
• 全ては流石に読み切れないので、一部の気になったファイルだけを読み解くことに集中する

英語についてはDeeplさんを駆使しました！

参加者

• 仕事でrubyを書いて1~3年くらいの人たち3人（運営側）
• ruby大好きつよつよ業務委託さん
• Go大好きつよつよさん

request_storeについて（読み解いた内容の頭出し）

※主観が多く含まれるので、マサカリある方はコメントによろしくお願いします

README.mdからわかること

• rubyでグローバル変数を使いたくなった時、先人たちはThreadを使用してその中にグローバル変数を定義していた。
• 昨今並行処理の出来るWebサーバーを取り入れることが多く、(ThinやPumaなど)それらとThread.currentの併用は非常に危険。なぜなら値が書き換わらないことがあるから…
• MRIでwebrickを使って実行すると1が出力されるけど、Thinを使うと1, 2, 3…と出力される。

def index
  Thread.current[:counter] ||= 0
  Thread.current[:counter] += 1

  render :text => Thread.current[:counter]
end

こういった背景があり、値の書き変わらない問題を解消したい！ということで生まれたのがrequest_storeだそうです。

テストコードからわかること

• 例えばhttps://github.com/steveklabnik/request_store/blob/master/test/middleware_test.rb を例に取ってみる

• setupでは

  • 設定したい値を持っておいてくれる、Storeクラスや、ミドルウェアクラスを初期化している。

• call_middlewareでは

  • プロトコルらしく、設定したい値の状態によってステータスコードとセットにして返している。（これ一般的にはどういう作業なんでしょう…名前があるなら知りたい。）
  • ほかのテストに必要な内容の準備をしているっぽい。ミドルウェアのお仕事という所感。

• test_middleware_resets_storeでは

  • 2回呼ぶことで値の書き換わりのミスがないかテストしている。

• test_middleware_does_not_mutate_response_and_does_not_overflow_stackでは

  • 名の表すとおり、スタックが溢れないことと、設定した値を詰めたオブジェクトは不可変であることをテストしている。

（つづきは別の記事で投稿します💡）

課題点

• rubyのコードにそこまで馴染みがない人にとっては、少し苦痛だったかもしれない

  • メタプロ的なことをやっている箇所は、普段のコードの中からは見かけないので、「わからないことがわからない」状態に足を突っ込みかけたのかもしれない

• rubyや技術的な背景に詳しい人が参加してくれなかったら、誤った解釈のまま進んでしまった可能性がある…

  • 今回だと、セッションとはプロトコルである、という前提の知識がなければ読み解けなかったところもあった。
  • 具体例: https://github.com/steveklabnik/request_store/blob/f79bd375e88f434428b876dbb5c8a51b569712aa/test/test_helper.rb#L11
  • この行はなぜAPIチックにレスポンスを返却しているのか、？だらけになっていたと思う。
  • OSIモデルを覚えたときに、セッション層が存在することは知っていたものの、今回の知識に結び付けられなかった無念さがある（個人的反省）

改善案

• 部活動の当日に思いついてほいっと始めてしまったので、数日取ってあらかじめコードリーディングしておく。

  • （ざっくりコードのレベルを見積もれるようにする）

• 解釈した内容を書き留めていただけるような、書記さんはいてくれたほうがいいかも？

  • （社内のナレッジ共有ツールで展開して、わからなかったことの復習ができそう）

おまけ

• 次は実際に読んだgem request_storeの内容を濃い目に共有したいっす