Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
入社数ヶ月のnewbieが 稼働7年超のプロジェクトに 型を導入して見えた世界
Search
Fu-ga
October 22, 2022
Programming
4
3.7k
入社数ヶ月のnewbieが 稼働7年超のプロジェクトに 型を導入して見えた世界
Kaigi on Rails 2022 登壇資料
Fu-ga
October 22, 2022
Tweet
Share
More Decks by Fu-ga
See All by Fu-ga
初めてのパフォーマンス改善
fugakkbn
18
6.1k
OSSから学んだPR Descriptionの書き方
fugakkbn
4
370
オンライン時代のペアプログラミング
fugakkbn
1
890
Types teaches success, what will we do?
fugakkbn
1
11k
What I can do to get the job smoothly
fugakkbn
0
340
introduction-to-rindokurb
fugakkbn
0
410
fbc-lt-code-review
fugakkbn
0
1.2k
Learn "QUIC" Quickly!
fugakkbn
0
350
タスクの洗い出しという壁 /fjord-lt-slide-fuga
fugakkbn
2
840
Other Decks in Programming
See All in Programming
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
ymtdzzz
4
1.5k
Pinia Colada が実現するスマートな非同期処理
naokihaba
2
150
Nuxt UI Pro、NuxtHub、Nuxt Scripts、Nuxtエコシステムをふんだんに利用して開発するコーポレートサイト@Vue Fes Japan 2024
shingangan
3
880
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
590
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
910
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.1k
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
330
役立つログに取り組もう
irof
26
8.6k
Why Spring Matters to Jakarta EE - and Vice Versa
ivargrimstad
0
950
開発効率向上のためのリファクタリングの一歩目の選択肢 ~コード分割~ / JJUG CCC 2024 Fall
ryounasso
0
360
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
1.6k
【Kaigi on Rails 2024】YOUTRUST スポンサーLT
krpk1900
1
240
Featured
See All Featured
Facilitating Awesome Meetings
lara
49
6k
Building Your Own Lightsaber
phodgson
102
6k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
We Have a Design System, Now What?
morganepeng
50
7.2k
Building Applications with DynamoDB
mza
90
6.1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Gamification - CAS2011
davidbonilla
80
5k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Transcript
Kaigi on Rails 2022 - 10.22(Sat) 入社数ヶ月のnewbieが 稼働7年超のプロジェクトに 型を導入して見えた世界 ふーが@fugakkbn
/ ESM, Inc
Profile ふーが @fugakkbn 2022年3月からエンジニアに(at ESM, Inc) Railsを使用したアプリケーション開発
gem_rbs_collectionのコントリビューター プロジェクトへの型導入を進めている Kaigi on Rails Organizer
動機 なぜ型に興味を持ったのか? 初めての型 TypeScriptで静的型に初 めて触れ、型があること のメリットを知った。 Rubyでも型の恩恵を 3.0からRubyでも静的型 を扱えるようになった が、プロジェクトには導
入されていなかった。 後押し 1on1でEMに「型に興味 がある」話をしたら「プ ロジェクトに導入してみ たら?」
None
×
コミュニティとの ”共生” このワードにピンと来た方は… @fugakkbn or agile.esm.co.jp まで!!
None
Kaigi on Rails 2022 - 10.22(Sat) 入社数ヶ月のnewbieが 稼働7年超のプロジェクトに 型を導入して見えた世界 ふーが@fugakkbn
/ ESM, Inc
アジェンダ newbieこそ型定義をするべき どのように導入を提案したか 導入する上での障壁
今日伝えたいこと newbie の皆さん 型情報から得られるフィードバック以外にもたくさんのメ リットがあることを知って欲しい もし型に興味を持ってもらえたなら、ぜひプロジェクトへ の導入を! 先輩の皆さん 同僚から型導入の打診があった時は今日紹介するようなメ リットを思い出して、ぜひ導入の支援をお願いします!
RBSの文法、書き方 導入の具体的な手順
用語の紹介 基本的なものだけ紹介 RBS Rubyの型を書くための言 語の名称。Ruby Likeな 書き方ができるため理解 やすい。 Steep Rubyの静的型解析機。
steep checkコマンドで Rubyファイルとrbsファ イルの型検査ができる。 ジェネレーター この発表では「プロダク トコードをもとにRBSの コードを自動生成するも の」として話します。
newbieこそ型定義をするべき https://unsplash.com/ja/%E5%86%99%E7%9C%9F/ak4hw4r6xio
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
皆さんに質問 プロジェクトに全部でいく つのメソッドが定義されて いますか? また、それらの引数にはど んな値が入りますか?
とあるアプリのメソッド数
とあるアプリのメソッド数
すべてを覚えておくのはムリ! 一度読んで理解してもしばらくしたら忘れてしまう 先輩のコードをレビューしているとき、テストコードを読み解くとき、障害発生 時に調査するとき…などなど、折に触れてメソッドの構造を理解するべきタイミ ングがあると思います。
そこで型ですよ 型があれば覚えておく必要がない なぜなら型を見ればどんな引数を渡してどんな返り値なのかが一目でわかるから 「これってどういうメソッドなんだっけ?」から始まる調査の手間は決して軽い ものではないはず。
rbsファイル アプリケーションコード
rbsファイル アプリケーションコード
rbsファイル 違う型を引数に渡そうとすると…
rbsファイル 型が違うことを教えてくれる!
型をつけたことで たくさんあるメソッドを 読み解きやすくなった
型をつけたことで たくさんあるメソッドを 読み解きやすくなった 型
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
プロジェクトの 全容把握 newbieな僕の最初の壁 その1
newbie 心の叫び どこに何が定義され ているのかわからな い。モデル同士の関 連どうなってるの? 「簡単な修正」って issue 振ってもらっ たけど…どこから手
をつければいいの? メソッドの処理が複 雑すぎて最終的にど うなるのかわから ん!!! コードジャンプ候補 に同名メソッドがた くさん出てきてどれ が正しいのかわから ない。。。
newbie 心の叫び どこに何が定義され ているのかわからな い。モデル同士の関 連どうなってるの? 「簡単な修正」って issue 振ってもらっ たけど…どこから手
をつければいいの? メソッドの処理が複 雑すぎて最終的にど うなるのかわから ん!!! コードジャンプ候補 に同名メソッドがた くさん出てきてどれ が正しいのかわから ない。。。
そこで型ですよ 型を書くことで理解が深まる 型を書くにはメソッドの使い方や使用時の挙動を調査する必要がある。 それを繰り返す中でどんどんわかることが増えていき、プロジェクトへの理解が 深まっていく。
型定義を進めるために嫌でもプロジェクト内のファイルを横 断的に見ることになる モデル同士の関連がどうなっているか理解が進んだり、この モデルにこんなメソッドがあるのか!などの発見がある それらに型付けする過程でユースケースやどこで使われてい るのかなどが自然とわかる
別のメリット 今後の自分の助けにもなる 型付けが進むとIDEの補完の正確度が上がる。正確度が上がると調査 も実装も速度が上がるため、相対的に同じ時間内で得られる情報量 が増える。
補完候補(型がない場合)
補完候補(型がない場合)
補完候補(型がある場合)
補完候補(型がある場合)
nextメソッドの定義を見たい!
ここでコードジャンプしようとすると…
候補がたくさん表示されてしまう
型をStringだと定義しておくと…
一発で String#next の定義元に飛べる!
型をつけたことで プロジェクトへの理解が進み 調査や実装もしやすくなった
型をつけたことで プロジェクトへの理解が進み 調査や実装もしやすくなった 型
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
gemの実装を見るのが苦手 newbieな僕の最初の壁 その2
苦手な理由 思い返してみると… 難しいコードがたくさん出てくる印象 どこから見ればいいのかわからない 「まだ自分には読めない」という先入観
型生成プロセス 良いサイクルが生まれます 調査 メソッドの構造 (引数の型、返 り値の型)や使 われ方を調査す る。 型定義 調査結果をもと
に型を定義して いく。このとき gem の型定義 の不足や誤りが 判明することも 実装の確認 起こっているエ ラーが型定義の 誤りなのかそう でないのかは、 gem の実装を 見る必要がある 反復 型定義はこれら の繰り返し。繰 り返しやってい るうちに実装を 見るのが日常に なる。 成果物 プロジェクトの 型定義はもちろ ん、場合によっ ては OSS にコ ントリビュート できることも。
steep checkで出たエラーに疑義がある場合 gemの型定義がなくて追加しようとするとき
steep check 実行時に見つかる
steep check 実行時に見つかる
steep check 実行時に見つかる
steep check 実行時に見つかる
実装元を確認する
Receive block!
gemの実装を見ることが "日常"になった。 あの頃の苦手意識はもうない
gemの実装を見ることが "日常"になった。 あの頃の苦手意識はもうない 型
gemの実装を見ることが "日常"になった。 あの頃の苦手意識はもうない 型 ※ただし読めるとは言っていない
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
OSSって なにから始めればいいの? newbieな僕の最初の壁 その3
OSS
OSS 選ばれし人がやること 初心者の自分にできるわけがない。技術に秀でたすごい人 たちがやること。
OSS 選ばれし人がやること 初心者の自分にできるわけがない。技術に秀でたすごい人 たちがやること。 自分にできることがあるはずない すごい技術を持った人たちが作ったものに自分が修正でき るところがあるわけない。
OSS 選ばれし人がやること 初心者の自分にできるわけがない。技術に秀でたすごい人 たちがやること。 自分にできることがあるはずない すごい技術を持った人たちが作ったものに自分が修正でき るところがあるわけない。 やってみたい気持ちはあるけれど… どこから手をつけたらいいのか、どこが修正すべきところ なのか、どうやってパッチを送ればいいのかナニモワカラ
ナイ。
型定義を始めるまでは…
型定義の誤り
gemの型定義の不足
試行錯誤の中での気づき プロジェクトの型導入をしている中で gemの型定義が足りなかったり間違ってることがあるなぁ
試行錯誤の中での気づき プロジェクトの型導入をしている中で gemの型定義が足りなかったり間違ってることがあるなぁ これってもしや…コントリビュートチャンスってやつ!?
OSSへの初めてのコントリビュート
None
コントリビュートは すごい人だから するものではない。 「使ってる人が 気付いた時にするもの」
コントリビュートは すごい人だから するものではない。 「使ってる人が 気付いた時にするもの」 型
なぜ? 理由はいくつかあります コードを読み解きやすくなる プロジェクトの全容把握の近道になる 実装を読むことへの抵抗がなくなる 無限にコントリビュートチャンスがある
興味を持ってもらえたら プロジェクトに型を 導入してみてください! newbieの多くの悩みを解決してくれます
とはいえ…
newbieに型を導入する 裁量なんてないんですが!?
どのように 型導入を提案したか https://unsplash.com/ja/%E5%86%99%E7%9C%9F/5Q07sS54D0Q
小さく少しずつ
第1ステップとして、rbs, rbs-rails, gem_rbs_collection などで大枠の型定義をそろえる
第1ステップとして、rbs, rbs-rails, gem_rbs_collection などで大枠の型定義をそろえる 第2ステップとして、生成された rbs ファイルの untyped を 正しい型に書き換えていく
第1ステップとして、rbs, rbs-rails, gem_rbs_collection などで大枠の型定義をそろえる 第2ステップとして、生成された rbs ファイルの untyped を 正しい型に書き換えていく
並行して、steep check でのエラーから gem の型定義不足 や誤りを見つけて修正する
gemもrbsも独立しているので剥がすのは簡単 主要なModelやAPIだけでもよい 型があってもなくてもプロダクトコードに影響はない Linterで警告が出たりノイズが発生することもない
CIには入れない
エラーの解消が目的ではない 目的はあくまで"開発者体験の向上" CIに組み込むと間違いなくエラーが出続ける CIがずっとredだと"オオカミ少年"状態になる… 型のエラーを検知したい訳ではない プロジェクト内の型を充実させることに集中する方が建設的
書きたい人だけ
型を書きたい人
型を書きたい人
型を書きたい
型を書きたい
型の恩恵を受けたい 型を書きたい
"書かなきゃいけないもの"にすると開発速度の低下ややらされ てる感からの生産性低下 "書く気力のある人"が少しずつ進めていくしかない。"型のあ る開発環境"を水面化で進める 機能追加のPull Requestに混ぜない。ノイズになる。型は個 別のPull Requestで余裕のある人が見る(見なくてもいい)
チームへの説明
newbieの独断では入れられない メンバーの理解と協力が不可欠 受け入れてくれたメンバーに感謝 ここまで説明したようなスタンス、メリットを伝える 「やっぱりダメだね」となった場合もすぐに剥がせる 一人でもメンテナンスしていく覚悟
導入の障壁 https://unsplash.com/ja/%E5%86%99%E7%9C%9F/sQ5yREHU_fI
gemの型不足
gemの型定義はまだまだ足りていない(2022年10月現在、 57個がgem_rbs_collectionにある) gemの型定義が増えるとプロジェクトに導入しやすくなるは ずだと考えています 興味がある方はぜひgemの型定義をやってみましょう!gem の型定義が増えて導入するプロジェクトが増えれば、型エコ システムの発展も早くなるかも?
RubyKaigi 2022 でそういう発表をしました https://speakerdeck.com/fugakkbn/types-teaches-success-what-will-we-do
変更への追従
コードの変更への追従 検知するソリューションがない メソッド追加、構造の変更など 自動で検知することができないため人力になる 別ファイルであることのデメリット 「気づいたときにやればいい」というスタンス
大量のエラー
プロジェクトに型を導入して全体で steep check を実行する と、大量にエラーが出るはず 今のプロジェクトでは1万以上のエラーが出る 繰り返しになるが、エラーを解消することに心血を注ぐ必要 はないと考えている
https://speakerdeck.com/soutaro/ruby-programming-with-types-in-action?slide=13
まとめ
newbieが型を書くメリットはたくさんあります!興味の裾野 を広げる一歩目にいかがですか? プロジェクトに型を導入することで得られる恩恵は限定的。 でも新しいメンバーがいち早くプロジェクトに馴染む助けに もなりそう。 小さく始められてランタイムに影響を与えないので導入しや すい。メンバーから打診があったらぜひ前向きな検討を!
型を通じて できることが増えた 取り組む意識が変わった 興味の幅が拡がった Rubyがもっと楽しくなった
波 紋 波 紋 https://unsplash.com/ja/%E5%86%99%E7%9C%9F/Tf18kgGiop4
None
型
誰がメンテしてる? 型
誰がメンテしてる? Steepのコマンドは内部 的にどう呼ばれてる? 型
誰がメンテしてる? どうやってコントリ ビュートする? Steepのコマンドは内部 的にどう呼ばれてる? 型
誰がメンテしてる? どうやってコントリ ビュートする? Steepのコマンドは内部 的にどう呼ばれてる? 型 ASTってなに? ASTってなに?
見える景色が変わった 見える景色が変わった 知覚できる世界が広がった 知覚できる世界が広がった https://unsplash.com/ja/%E5%86%99%E7%9C%9F/1lfI7wkGWZ4