Railsの賞味期限を延ばす方法をまとめてみる 〜 大規模開発でもRailsを快適に使う
はじめに
年末になりアドベントカレンダーが盛り上がってますね。Railsのエントリーも賑わっています。
以下のエントリーに触発されて、大規模な開発になっても少しでもうまく開発が進む方法まとめてみようと思いました。
考え方
この記事では、DDDやアーキテクチャについて議論は取り扱わず、具体的なRubyのコーディング方法を中心にまとめていきます。
まず、原則的になぜRailsが大規模に向かないのか？開発が進むにつれしんどくなっていく理由について考えてみます。
大規模開発に向かない理由：
- クラスやオブジェクトの参照箇所が正確に把握できない。このため、リファクタリングはもちろん機能追加などがやり辛く、開発のスピード・品質が悪くなっていく。
こんな経験ありませんか？
- Gemのソースコードを追っていたけど、メソッドの定義がどこかわからなくなってしまう
- ネストが深すぎて処理内容がよくわからなくなる
Rubyのようなスクリプト型言語とコンパイル型言語の大きな違いの１つに動的な関数呼び出しがあり、これが規模が大きくなるにつれ開発を難しくする要因の大きない理由になっています。これを解決する手段として、DDDなどの手法を採用することも多いと思います。
参照箇所がなるべく明示的になるコーディングをする
参照箇所が明示的にわかるようにするには、大まかにいうと "メタプロを避ける" ということが言えます。
具体的には、
- 動的なメソッド定義を避ける=
-
#respond_to?を使って処理を変えるコードは避ける -
#sendを使わない - 静的な処理を動的に処理しない
（例： viewでActiveRecordのattributeを.eachを使って表示を作る ）
という感じです。
メタプロではありませんが、Railsの標準機能でも避けた方が良い機能もあります。
- Concernなどのモジュールのinclude/mixinは避ける
別クラスに移譲するべき - ActiveRecordの
before_*/after_*を避ける
サービスパターン、コマンドパターンなどで別クラスからメソッドをコールする
コーディングルールを定める
より実践的な運用を考えると、ここまで紹介してきたようなポイントを、コーディングルールとして定めてチームで共有しておくと負債の増加が防げて望ましい状況ができます。
また、これらのことが守られているかはレビューでチェックする必要が出てきますが、レビュアーの負担が増えるため、 querly などのツールで検出することが理想的です。
これがあれば新規メンバー加入時も、チームの負担を少なく品質を守り、また新規メンバーもなるべく自力で馴染んでいくことができます。
雑感
まとめてみる ということで雑記帳のようになりましたが、そのうち統合的に再編集したい気持ちもあります。
ぜひ、よくわからないこと（避けるべき理由や対処法）や他にも気をつけた方が良いポイントなどコメントもらえたら嬉しいです
Discussion