WebアプリとMVC論

えふしん @fshin2000

2002年ぐらいから自前でMVCを作り、そのあとStrutsを触って、PHPに入って、古いMVC型のフレームワークを触って、Railsタイプのフレームワークを触った結論として、Webサイトに、かっちりしたMVCは不要。理由は、ほとんどの画面がユニークで再利用が効かないから。

えふしん @fshin2000

むりやり再利用しようとすると、共通メソッドの引数が増えて行く。その時点で再利用に無理があるということを示す。引数による例外は、条件分岐を一つのメソッドに押し込んでるだけ。この事を指摘してくれたのはD2E2時代の人たちだったなぁ。

えふしん @fshin2000

Webというのはほとんどの処理が、「validationを行い」「送信されたデータを保存し」「データ引っ張ってきて、どのように画面を表示するか」で構成される。逆に言うと、それだけしかない。もう少しロジックたるロジックがある場合は、モデルにしろロジックにしろ役割も増えて行くのだが

えふしん @fshin2000

エンジニアは、同じコードを二度書くのが嫌だから一つのロジックに押し込もうとするが、Webは変化を許容し、スピード優先。メソッドにまとめたからできません、という状況は許されない。冗長が故のメリットというものもある。

えふしん @fshin2000

もしかしたら、明日変わるかもしれないので、整理することが正義かどうかはわかりません、ということ。明らかに共通な処理ってのは、ちゃんと眺めてみるとわかるけど、そんなにないの。明らかにまとめられそうな部分は、既にまとめてあるわけなのであります。僕も何度も同じ処理を書くのは嫌いな人なの

えふしん @fshin2000

最大の問題は、２ちゃんねるのスレと同じ問題が起きる事、エンジニアにとっての典型的な思考方向が、今の選択肢とあわない場合に、同じ道を辿らないと納得する形で今の結論に到達しないこと。暗黙的にやられて時間だけが失われる、それだけが怖い。まじで怖い。聞いてもらえば全部説明するから。

えふしん @fshin2000

最終的には８年以上このことをずっと考えて仕事してるから黙って信じてくれって話なんだけど、そういうのはなかなか難しいね。かと言って、そのトレースを待ってるわけにもいかず、どこかで無理矢理、押し込んでしまうことがある。そこら辺が問題なんだよね。

えふしん @fshin2000

あ、リプライ見てて思ったけど、単一ライブラリにまとめるって怖いことだから。単一障害点を自ら作り込んでることだったり。そういうところは、テスティングフレームワークやテストスクリプトで後方互換性を担保することが求められますね。

えふしん @fshin2000

Webで単一の画面をただ表示するだけなら、テスティングフレームワークっていらないと思うの。じゃなくて、複数フォーマットのデータ送信、変換処理とか、ソーシャルブックマークのURLの扱い、みたいな進化していくコアロジックに関しては、テストスクリプトで安全を確保するのは必要ですね。

えふしん @fshin2000

Webでありがちで割と最悪なのが画面設計を無視したヘッダ、フッタの共通化。初期のHTMLだけ見て判断せずに、SEOとかも考えて、ちっとは相談せえよと。 RT @tokotokoya: 「共通化されてるから影響大きいです。」ってありがち。

えふしん @fshin2000

役割によって見ている視点が違うってのがあって、HTMLをただの文字として捉えるか、構造として捉えるかで、共通部分の切り出し方は変わってくる。多くのサーバエンジニアは、HTMLを文字としてしか捉えないから、ざっくりbodyの直下まで共通部分として一つのファイルに切り出したりする。

えふしん @fshin2000

iPhoneアプリのコードを書いた人はわかると思うけど、フレームワーク側に明確に存在するUIの枠組みに入るためにMVCでプログラミングする必要があるよね。Webはアウトプットが所詮HTMLなので、やっぱりsmalltalkのMVCとは違うよね。WebアプリのVは鮭の放流に近い。

えふしん @fshin2000

昔、Java Servletでモデル作って高度に整理されてる感が、なんか仕事してる感みたいな風に思ってたけど、画面に一つ情報が増えました→モデル、ロジック、View,テンプレートに渡って変更が加わって、それ分けてる意味ないじゃん！

えふしん @fshin2000

しかも共通化されたモデルやロジックに処理が追加されることで、テストしなきゃいけない範囲も広がる罠。LLでハッシュで全部持ち歩く方が安全という皮肉。結局、画面を生成するぐらいの話に仰々しい分離は大げさすぎるわけです。MVCはもっと大きなアーキテクチャの話だと思う。

えふしん @fshin2000

問題は、設計して整理することが、なんとなく仕事してる感になってしまうところなんだよなぁ。それが求められて適切な整理なら良いんだけど、往々にしてエンジニアの考え過ぎということがあったりして。設計レビューは大事なんだけど、それがやりやすいのが何を隠そうJavaという皮肉が。

えふしん @fshin2000

JavaにおいてMVCと分けるのは仕方ない。HttpServletと、DBクラスから生成されるクラスは別の世界なんだから。LLのフレームワークはコードを整理してるだけ。Javaの制約に基づくデザインパターンをLLに取り入れるのは無駄が大きい。O/Rマッパーもだよ。

えふしん @fshin2000

O/Rマッパーはどこを注視するかで変わってくるが、結論としてはSQLが苦手だからO/Rマッパーに委ねるってのは、自分のキャリアの首を絞めるだけだからやめた方が良い。joinしたコードから問題点を夢想できるエンジニアじゃないと信用できない。explainするときどうすんの？とか。