Leaner 開発チームの黒曜(@kokuyouwind)です。
週末のゾンビランドサガLIVEを楽しみに今週を生き抜いています。
Rubyの型システム勉強会
実施背景
先日のRubyKaigi Takeout 2021で機運が盛り上がったこともあり、社内で Ruby の型システムを活用していきたいよねという話が出てきました。
前回書いた記事 で RBS Collection を試したのも、実際の使用感を見てみたかったという部分があります。
一方で Ruby の型システムはシグニチャ定義を別ファイルにする必要があったり、検証用のツールが複数合ったりと独特で、そもそも全体像をつかめていないというメンバーも複数人いました。
このあたりは自分の興味分野で RubyKaigi のセッションを追いかけていたこともあり、社内で勉強会を開いて下地を固めよう、ということになりました。
勉強会で使用したアジェンダ
以下は実際の勉強会で使用したアジェンダなので、文体が異なります。
大まかに、 Ruby の型システムにまつわる仕様やツールを概説したうえで、演習やコードリーディングなどを行い理解を深める、という流れで実施しました。
型システムの概要確認
現状の全体像を掴むには pocke さんのスライドがわかりやすい。
- rbs は Ruby 型定義言語
- https://github.com/ruby/rbs で開発されている
- .rbs ファイルに型定義を記述する(インターフェイス定義と実装が分離されている)
- 型を記述する方法のみ定義されており、構文解析器は提供されるが 型検査機能は提供されない
- 標準ライブラリの型定義は同梱されている
- 外部ライブラリの型定義は https://github.com/ruby/gem_rbs_collection にある
- rbs を利用するツールは別に開発されている
- Steep: rbs の型定義が実装と適合しているか検査する型検査器 https://github.com/soutaro/steep
- TypeProf: ruby を型レベル実行することで rbs を生成する型解析機 https://github.com/ruby/typeprof
- rbs とは別に、 rbi という型定義言語が Stripe によって開発されている
- Sorbet: https://sorbet.org/
- Ruby 3.0 で RBS が開発される前から、 Stripe が独自に開発していたもの
- 言語内 DSL により .rb ファイル内に埋め込みで記述する(インターフェイス定義と実装が結合している)
やりたいこと
以下の中から気になる人が多いやつを優先してやっていきたい。
- 小さいサンプルコードを作って steep で型チェックするところまで手を動かしてみる
- https://github.com/soutaro/steep の usage 通りに手を動かすのが良さそう
- いずれかのライブラリの rbs コードリーディング
- rbs の Syntax を確認
(アジェンダここまで)
実施で得られた知見
Steep の Usage を動かした際のトラブル
Steep の Usageを手元で動かして型チェックの流れを確認しようとしたのですが、なぜか書かれているものとは違うエラーが出てしまい試行錯誤することになりました。
開発が活発なライブラリなので README が最新の内容に追従していないのでしょうが[1]、こういったトラブルがあると勉強会がデバッグ会になってしまうので、講師役は演習内容を事前に試しておいたほうが良いなと反省しました。
コードリーディングでの in/out 議論
実例をコードリーディングしてみようということで、構造が単純そうな ActiveSupport の型定義を順に眺めていきました。
大抵の型は比較的読みやすかったのですが、Hashの型定義で出てくる unchecked と out というキーワードはわからず全員で調べることに。
RBS Syntax の Class declarationを読んで out が共変(covariant)の指定であることがわかったのですが、共変・反変を知らないメンバーもいたので今度はそちらを確認することになりました。[2]
共変・反変についてはいくつかの資料を見たのですが、なぜ TypeScript の型システムが健全性を諦めているか内にある「関数パラメータは反変性を持ち、 Array は共変性を持つ」という説明がわかりやすく全員納得していました。
RBS の仕様という点からは少しずれた深堀りになりましたが、結果的に Ruby に限らない型システムの理解が深まる良い議論でした。
勉強会についての振り返り
この勉強会について感想を募ったところ、普段の仕事では得られない知識が得られるので定期的に勉強会をやりたいという意見が出た一方で、あまり業務から遠すぎる知識だと使う機会がないのである程度業務に近い領域の題材を扱いたいという意見もありました。
この辺りを踏まえ、次回以降は業務で扱っている技術領域や困っていること・今後やりたいことをメンバーに募り、それを元に都度題材を選定していくことになりました。
これがうまくいったかどうかについては、開催を重ねた上で改めて記事にするつもりです。
宣伝
Leaner Technologies では社内勉強会で知見を深めたいエンジニアを募集しています！
Discussion