Kaigi on Rails 2024 で「入門『状態』」という内容で登壇してきました。

Kaigi on Rails 2024 で登壇してきました。

発表したスライド

speakerdeck.com

伝えたかったこと

テーマとしては大きく2つありました。

状態は極力持たないほうがいい、もたせるなら最小限かつ管理したいものを明確にする。
変数の再代入というのは変数に状態変化を生んでしまう。そのため可能であればしないようにする。

補遺編

今回のプロポーザルの動機

今回の起源としては「変数への再代入はやめよう」が一番最初にありました。そのためプロトタイプ的な記事は以下になります。

変数代入を複数回行うと何が良くないのか、どうするといいのか - コード日進月歩

特にRailsではControllerのインスタンス変数設定に関しては改修を繰り返すと再代入をするコードの登場が増えがちです。そのためその「再代入の何が悪いのか」というところを突き詰めて行くと変数の状態に関して移り変わるところの弱みについて説明をしないと納得感を持ってもらえないので、そのあたりに焦点を当てる話をしました。

今回の発表で苦心したところ

どうしても「変数の中身が何度も切り替わると何が悪いのか」ということを出発点にしているので、状態という話のブレイクダウンと合わせて話の作り方はだいぶ苦心しました。

また、つらみが軽減されていく様をわかってもらうには実コードで体感してもらう他ないかなと思ったので結局以下のような感想の資料に落ち着いたのでした。

すごいわかりやすい状態に関するリファクタリング入門だった#kaigionrails_red
— はるかさん (@harukasan) 2024年10月26日

盛り込めなかったもの

当初は状態を扱う上でのつらさを一通り話したあとに、状態のいなしかたで色々紹介するところまでいきたかったのですがかなり削りました。以下が削ったようなトピックです。

オブジェクト生成を純粋関数化して、状態を決定づけるものを引数化する
完全コンストラクタ化し、オブジェクトそのものを変化させない
どうしても状態を持つ必要がある場合のステートマシン（状態遷移図）
発展話題としてのFluxやReduxの状態遷移の考え方

案外に状態を語っている資料は少ない

自分自身、歴史的なところを抑えつつ資料に盛り込むスタイルをよくやるので今回もそれをやろうとしてみたのですが、わかりやすく変数と状態に語っているものが少なく、オブジェクト指向の文脈ではいくつかあったのですが織り交ぜるとややこしくなりそうなのであまり深くは掘ることをやめました。その結果としてかなり自分の経験色が強めの話として整理されました。

地続きの話としての過去スライド

いままでの登壇につながるものがあるなというのを２つ感じました。まず1つは去年、脳プログラマーに感銘を覚えてLTをしたのですが、結局状態を増やしすぎないとというところは脳の効率化にもつながるなと感じたところがひとつ。もうひとつはbefore_actionでインスタンス変数セットしていると再代入が乱発するので、before_actionの使いかたを再考すると状態を減らす方向に行くなと感じました。

なお、過去の話は以下リンク参照のこと

今回の発表タイトルのインスパイア元

今回のタイトル、実は5年前に見たスライドが元ネタとなっております。

https://speakerdeck.com/fujimura/ru-men-ming-qian

登壇後記

もともとは「純粋関数」を主題において話すといいのではと思っていたのですが、このあたりを社内で話したところ別の切り口の示唆を得たのでありがたかったです。
苦心したところのパートでもあるんですが、資料の構成は何度か見直したりしました。そのためChatGPTに色々投げたりしてやっていたのですが、肯定的な返ししかしてくれなかったので資料が迷走する瞬間などがありました。
- ただブレスト相手としては優秀だったので、うまく活用していきたいと思いました。
健康的な生活を送ることに重きをおいていたので、前日に徹夜…などはなかったのですが、かなりギリギリまで表現の調整などはしていました。もう少しこのあたりうまくできるように練度を上げたいですね…
今回もいままでどうように初学者向けトピックを扱っていたので手応えとしてはなかったのですが、感想ブログなどを見ると取り上げてくださっている方がいるのでいくらかは届けた意味があったようでした。書いている皆様全員に感謝。