Rails で複雑な処理をつくったお
この記事は Ruby on Rails Advent Calendar 2014 - Qiita の17日目です。
前回は @gogotanaka さんの Railsを作った男たち - Qiita でした。
複雑な処理 is つらい
複雑な処理を避けるには？
- 処理の複雑さ＝仕様の複雑さ
- 複雑な仕様を簡単な仕様にすれば、処理も簡単になる
- 最初の段階でドメイン設計やモデリング、デザインを頑張れば簡単にすることは可能
- 最初にリソース投下して設計する事、また途中で定期的に再設計、リファクタを繰り返し整理された設計を維持し続ければ複雑なドメインは避けられる。つまり複雑な処理も避けられる、はず。
ところがぎっちょん
- すべての複雑な仕様を簡単な仕様にすることはできない
- 仕事の要求上複雑な仕様が湧いてくることは避けられない
知らなかったのか仕様からは逃げられない
レポート機能を作らざるを得なかった
- 解析軸は可変でなければならない
- 解析期間も可変でなくてはならない
- ほか付帯条件もいろいろつけられるようにしたい
- 別システムにするほどの複雑さではない
- 意外と細かいレポートの要求機能
苦戦する実装
- レポートでたびたび呼ばれる集約関数がActiveRecordと微妙に食い合わせが悪い
- scopeの中に処理が書かれるケースが続発
- スロークエリの巣になるケースも
- 「便利な機能が欲しい」「可視化のために」更に増える要求
- 速いクエリと表示しやすい形のクエリはしばしば排他的になる
やったこと
- レポートのModelクラスが汚れてしまうのは仕方がない。
- 速いクエリを投げて、表示しやすいように整形する変態メソッドを作る
- ほかを綺麗にするために汚れ役が必要だった
汚れ役を一つにおしつけて
- 面倒が起きたらだいたいこいつのせい。
- 調査時の容疑者探しが楽になった
- 引き継ぎ時に重点的に引き継ぐポイントが明確に。
結論
- この複雑な世界で、(仕様が)綺麗でままでいるのは難しい
- 誰かが汚れ役になる必要がある
- 引き継ぎは忘れてはダメ。絶対。
