アクションとロジック（今さら設計の話）

設計勉強会以来なんか書きそびれてたけど設計について書く。

アクションの中にロジックを書くかどうか。これについては2通りの意味があると思っている。

1つ目は、何かバグが出た場合にそれがフレームワークの問題なのか、実装したアプリケーションの問題なのかを切り分けることができるということ。アクションにはロジックを書かず、別のクラスなりに切り出しておけばその辺の検証が簡単になる。フレームワークにバグがある、という場合もそれなりにあることだし。

2つ目は、テスト容易性。ロジックを単体で、しかもテストしやすいように実装しておけば仕様の変更が発生した場合に回帰テストなどをしやすくなる。モダンなフレームワークだとフレームワーク自体がテスト機構を備えているけれど、どのみちロジック単体でテストできるようになっていたほうがいい。

とまあ、アクションにはロジックを書かない方がいいと思うんだけど、一人で作業する小さなアプリケーションの場合だと、アクションに直接ロジックを書いてしまうことも多い。その辺の手っ取り早さはきちんとリスクを考慮して判断されるべき。

お仕事でチームで開発するときは絶対にアクションとロジックは分離すべきだと思う。実装の役割分担ができるという意味でも、余計に。

ちなみにロジックの再利用ができるからロジックは分離した方がいいというのは結果論であって、目的ではないと思います。