【序章】Railsのリファクタリングに立ち向かうための教科書
※ この記事は「Railsのリファクタリングに立ち向かうための教科書」シリーズの序章になります（1/5）
★【序章】 問題はどうして起こるのか ~ 方針とアーキテクチャについて
【第1章】 ModelとServiceを紐解く
【第2章】 ApplicationServiceの導入
【第3章】 マイクロサービスを見越した実装
【最終章】 リファクタリングを通してチームを強化していく
問題はどうして起こるのか
私の経験上、多かれ少なかれ違いはあるものの、どのような過程を踏んでRailsのコードがカオスになってくるかには、ある程度傾向が見られます。まず、自分の関わっているプロジェクトの現状がどうなのかを判断するために下記の質問に答えてみてください。
Q. app/以下のディレクトリはそれぞれどういう役割を持っていますか
これに答える自信がなければ、リファクタリングを要する匂いが既にしてきているのかもしれません。ぜひ引き続きこの記事と私のブログを読み進めていってみてください。
さて、ではどのようにしてRailsのコードがカオスになってくるのでしょう？もう何度も見てきたRailsがカオスになるパターンが下記の通りです。
- Fat Controllerになる
- Modelに移す
- Fat Modelになる
- Serviceを作ってServiceに移す
- Serviceがカオスになる
- どうしていいかわからない...
耳が痛いという方もいらっしゃるのではないでしょうか？これは本当によくあるパターンです。こうなってくると、先程の質問に対して「Service」が何をしているのか答えられなくなります。また、Modelに対しても同じようになってしまっているかもしれません。でも安心してください。これからこの問題を解決していきましょう。
方針とアーキテクチャ
では、早速どのようにリファクタリングを進めていくのかという方針を決めていきます。私の提案は下記の3つです。
1. どのレイヤーに何を置き、どう書くべきかを明確にすることをゴールとする
2. 単一責任の原則を厳守する
3. アーキテクチャの方針をよく理解し、取り込む
ひとつずつ見ていきましょう。
1. どのレイヤーに何を置き、どう書くべきかを明確にすることをゴールとする
1は最終的に一番重要になります。これができていると、なにが嬉しいのかというと
- 新しい人が入ってきてもすぐにコード方針を理解出来る
- レビューの視点がクリアになる。何をレビューすればいいかわかる
- 新機能を追加するときもどこに何を書くかで迷うことがなくなる
1は3と重なる部分もあるのですが、ここがゴールだとメンバーみんなが理解することが非常に重要です。
2. 単一責任の原則を厳守する
これはよく聞く話なので当たり前だと思う方も多いのではないでしょうか。ただし、Railsで見過ごされがちなのもこの視点であるのは間違いありません。とくにActiveRecord継承クラスとServiceクラスでこの原則を無視したコードが数多く見られます。ActiveRecordは便利なORMですが、付き合い方を存分に気をつける必要があります。そして、この単一責任の原則を守るだけで、現状のコードでもかなりの部分でReadabilityが向上することに驚かれることになると思います。ちなみに、私がチームにジョインする時は、まずこの原則に基づいたリファクタリングをメンバーにみせ、これを続けていけばかなり良くなっていくのではという期待感を持っていただいてから1と3を進めていくという手順を取ります。
3. アーキテクチャの方針をよく理解し、取り込む
最後になりますが、アーキテクチャを決めます。要はMVCの限界をどう乗り切るかというところです。私がここで用いるのはRailsに合わせたDDD（Domain Driven Design）です。DDDというと難解で尻込みする方が多いのもわかりますが、それほど難しいものではありません。特にRailsの上でDDDの長所を取り込むにはどうすれば良いかという視点で開発するので、話も少し簡単になります。これは後の記事で詳しく解説していきます。まずは全体像がどのような形になるかをここで見ておきましょう。この図はこの後何度か登場することになるかと思います。
いかがでしたでしょうか。少しでも関心をお持ちいただき、次回を楽しみにしていただけると、私としても非常にありがたいです。
次回は「【第1章】 ModelとServiceを紐解く」を書いていこうと思います。
それでは！
