はじめまして。株式会社TOKIUMで経費精算チームのメンバーとしてWEBエンジニアをしている城戸と申します。
10月21日(金)-22日(土)で開催されたKaigi on Rails 2022にて、2日目に聴講したセッションの中で印象に残ったセッションを紹介します。
この記事では、以下の2セッションについてご紹介します。
入社数ヶ月の newbie が稼働7年超のRailsプロジェクトに"型"を導入して見えた世界
解説
株式会社永和システムマネジメントさんに所属する、Fu-gaさんによる登壇です。
Ruby 3.0からRubyに型が導入されました。それに合わせ、実際にサービスに型を導入した際の気づきがテーマです。
特に、Newbieこそ型を書くことで多くのメリットを享受できるという点にフォーカスし、分かりやすく解説して頂きました。ここには、4つのメリットがあります。
- コードを読み解きやすくなる
- プロジェクトの全容把握の近道になる
- 実装を読むことの抵抗がなくなる
- OSSコントリビュートのきっかけになる
確かに、これらのメリットは大きいです。
導入できるものなら是非ともしたい所です。
が…実際に重い腰を上げるのは中々大変そうです。
特に、Newbieに型導入の裁量なんて与えられない！という障壁が発生する事は容易にイメージできます…(泣)
しかし、永和システムマネジメントさんでは、下記の根拠や施策のもと、積極的に型を書くモチベーションや環境が醸成されているという事です。
- 型ファイル作成のワークフローを決める
- (最初に大枠の型定義を rbs/rbs-rails/gem_rbs_collectionで揃え、次のステップで生成したrbsのuntypedを正しい型に書き換える、のように手順化しておく)
- 主要なModelやAPIに対して型を導入するだけでも充分に価値がある！ 全てのコードに対して導入する必要は無い
- プロダクションコードにはどの道影響しない。ので、実装を恐れない！
- 型を書くのは、希望するメンバーだけ。機能開発のプルリクとは分ける。書きたくない人は書かない。
感想
Ruby界隈において現在、型の導入は最もホットなトピックだと思います。
弊社でも、導入したいという声は上がっていましたが、正直今まで中々ハードルが高く感じてしまい、実現するビジョンまでは見えておりませんでした。
しかし、今回の登壇を聞いて、あまり肩肘張らずに取り組めるものなんだな…と思えた事は大きな収穫です。
「主要なModelやAPIに対して型を導入するだけでも充分に価値がある」「プロダクションコードにはどの道影響しない。ので、実装を恐れない」の2つを聞いた時、ハッとさせられました。
余談ですが、Fu-gaさんはなんと、異業種からエンジニアに転向してまだ7ヶ月らしいです (！！！)。
私も2年半前に異業種からエンジニアに転向してきた身なのですが、歴が浅くてもこうしてOSSにコントリビュートし、こういった大規模なカンファレンスに登壇されている方がいらっしゃるんだな…と、そういった意味でも非常に刺激になりました。
実践 Rails アソシエーションリファクタリング
解説
株式会社ANDPADさん所属の、Kei Shiratsuchiさんによる登壇です。
一般的に、Railsにおいてポリモーフィックはアンチパターンだと言われています。
「万物と万物を、何でもアリな形で関連付けられてしまう」ためです。
そして、ANDPADさんの中でも今までポリモーフィックを多様し開発してきたものの、サービスが成長する中でドメインが複雑化し、それに伴って今までに作成したポリモーフィック関連付けが切り離せなくなり負債化しているとの事です。
それらを中間テーブルを用いて1つ1つ解消している、という内容のセッションです。
ポリモーフィック解消のフローについて非常に分かりやすく解説してくださりました。
- 移行先モデル(中間テーブル)の作成
- after_createコールバックを使うことで、新旧テーブル両方に書き込むようにする
- 旧アソシエーションによる既存データを、新アソシエーションにバッチ処理でコピーする
- アプリケーション側で、新アソシエーションに置き換える
- この時点では旧アソシエーションは削除せず、引き続き新旧テーブル両方に書き込むようにする
- 本番環境でしばらく様子見。「旧アソシエーションでの書き込みが発生していないか？」の抜け漏れ検知期間
- モジュールのself.extendedを利用し、旧アソシエーションが利用されたらログを出力させるようにする
- 4.の結果しばらく問題が発生しなければ、旧アソシエーションを削除 & 新アソシエーションの名前を旧版のそれへ変更
- 旧ポリモーフィック関連のカラム(id, type)をnullへとUPDATE。「リファクタリング対応済み」という事がひと目で分かるように
上記のやり方を遵守する事で、下記2点のメリットを享受しつつリプレイスに対応できるのです。
- サービスを停止させない
- 新版で問題が発生すればすぐ旧版に戻せるよう、可能な限り安全に
感想
今回ご紹介頂いた、「サービスが成長する中でドメインが複雑化し、切り離せなくなっている」という事例は、まさに現在の弊社でも同じく発生しており、実体験と照らし合わせて非常に共感させられる内容でした。
弊社でも、経費精算のサービスと請求書管理のサービスが同じリポジトリ上に共存しており、非常に密結合してしまっているのです (ポリモーフィック関連も多用しています)。
そして、ご紹介頂いたリファクタリングのプロセス自体についてもいわずもがな、非常に深く学べる内容だったと思います。
私は、本格的なデータ移行リファクタリングを経験した事はまだ無く、「サービスを停止させない」「新版で問題が発生すればすぐ旧版に戻せるように」という所まで今までお恥ずかしながら考慮出来ておりませんでした。
今後の弊社でも使える知見で、実践的な知見共有をして頂けたと思います。
全体を通して
この日は全てのセッションを聞きました。このブログ上では特に印象に残った2セッションについてまとめましたが、どのセッションも本当に楽しく、非常に沢山の事を学ばせて頂きました。
また、夜の懇親会でも非常に楽しく交流させて頂けました。
この会を主催してくださった運営スタッフの方々・登壇してくださった皆様・スポンサーの皆様へは本当に感謝してもし切れません。
こうして会社を超えて、コミュニティが盛り上がる事自体への素晴らしさを痛感しました。
弊社としても、今後も最大限にこの界隈の発展に貢献してゆきたいと思います。
改めて、懇親会やブース等で関わってくださった皆様、本当にありがとうございました。
また来年も、よろしくお願いします。
Discussion