FatControllerに育ったRailsを改善した話

開発の速度を優先するあまりコード負債を多く抱えてしまう、といったプロジェクトは少なくないはずです。私たちが開発している Lynx でも、気づけば Controller が肥大化し、メンテナンス性やテスタビリティを大きく損なってしまう状況に陥っていました。本記事では、Fat Controller問題にどう向き合い、どのように改善していったか、その背景と実際の工夫を共有します。

Transcript

1. FatControllerに育ったRailsを 改善した話 2025/10/07 ｓｔａｋ
2. • 23歳、2025年3月に電気通信大学を卒業 • Ruby on Rails 業務経験3年 • 現在はフリーランスとしてスタートアップ企業でソフトウェアを開発 💪 ◦ 株式会社タイムラボで「Lynx」というカレンダーを同期する Webアプリを鋭意開発中 ◦ Otaac合同会社で推し活を支援する toC モバイルアプリを鋭意開発中 • X: @stak_22 ｓｔａｋ / Shota Takahashi
3. みなさんは、 Fat Controller の地獄を 味わったことがありますか？？
5. Rails Way に則って、 MVCのほかに 不要なレイヤーは作らない！ 💪 スタートアップなんだから、とにかく スピード重視！💪 一刻も早くリリースしないと会社が 終わってしまう！ 💦 当時の生産者の声（憶測）
6. その結果… • privateメソッドが7つのRESTアクションにまたがって肥大化 • 責務が不明瞭になり、修正がデグレを招きやすい • テストが書きづらく、カバレッジや品質が安定しない 「できるだけ触らないで」なコードになる😸
7. 過去に借りた負債は返さないといけない 負債は後で返せるっしょ！！ とりあえずユーザーのために 一刻も早いリリースだ！！ リリースしたいのに 負債を返さないと リリースまで辿り着けないよ〜〜〜
8. 重い腰を上げて、負債を返します。 問題なのは、思想もなければルールもないという状態 ⬇ まずは方針を決めて、保守性を上げていこう！
9. CQRSで責務分離へ MVCの他に、domainレイヤーを追加🚀🚀🚀 具体的な処理はドメインに切り出そう💪 app - controllers - domains ← 🆕!!! - features - commands（書き込み専用） - queries（読み込み専用） - models - views
10. <設計思想> 1⃣ ControllerはHTTPの処理だけに専念 2⃣ 1 Action = 1 Class 3⃣ Resultオブジェクトを定義
11. 1⃣ ControllerはHTTPの処理だけに専念 • 中途半端なprivateメソッドの共通化を避けることができる。 • テストが行いやすくなる。
12. 2⃣「1 Action = 1 Class」の原則 仕様変更やバグがあったとき、 最小の影響範囲のみの考慮で済む❗
13. 3⃣ Resultオブジェクトを定義 クラス単位での Input と Output が明確になる❗ ※ dry-struct と dry-validation という gem を使っています
14. 改善による成果 • 開発速度の向上 • デグレ減少 & 修正速度の向上 • テストカバレッジの改善（62% → 80%） • 新規メンバーのキャッチアップ容易化
15. 改善の前後で 可読性が圧倒的に 異なる!!
16. テストピラミッドの正 常化による 保守性の向上!! Unit Test Request Test Controller のテストは HTTP通信が絡む部分 Domain のテストは ロジックに専念
17. まとめ • Fat Controllerは短期的には開発スピードを上げるかもしれないが、長期 的には負債化する • CQRSによる「1 Action = 1 Class」で責務を明確化 • ControllerはHTTP処理だけに専念、ロジックはドメイン層へ • テストピラミッドを整え、リファクタや改善を継続的に行える状態に
18. 学んだこと • RailsにおけるServiceクラスの良し悪しは議論になりがちだが、チームに とって適切な方針であるならばそれが答え • レイヤー設計はきっちりやるべき • 負債を許容するチームにはしたくない
19. いいねお待ちしてます！
20. Thank you!!🥰 please follow me! X: @stak_22