新機能を作るときに思う事 MVC編

10月も終わるっていうことは配属されて4ヶ月が終わろうとしているのですが、すでに3年目くらいの気分で居ます。

新卒の椛澤です!っていう単語を週1くらいで使うんですが、たまにゲシュタルト崩壊起きて、大変です。

 

さて、今日は新機能を作る時にいっつもはまっていることをなんとなくまとめて、

あわよくば読者の方のコメント期待しつつ、どうせ何もつかないだろうから、三年目くらいになって振り返ったときに、こんなことで悩んでいたのか。と振り返れるようにそれとなくまとめておきます。

 

8月に新機能を作って思ったのが、MVCで設計した後、どこから実装するか?という問題です。

といってもMはDBとのやりとりだけですし、Vは出力する情報だけにするという設計思想になっている僕は、結局内部設計と言いますか、Cの実装にいっつもはまります。

 

学生時代に作っていた頃は、とりあえず必要な画面を空ファイルでもいいから適当に作って、ここにこういったアクションがあった時にこの情報が欲しい、あるいは渡したいから、こんな感じのCを書いて、それに対応するMを作る。

みたいなノリで作っていました。

 

8月もそんなノリでやろうとしたところ、Vで出す情報/受け取る情報が少ない割にはvalidationやら権限チェック、CSRF対策などでCで記述すべき実装の量が多くなり、疲れたからMから実装しようかな...と逃げに走ったせいもあり、期日には間に合った物の、いわゆる社会人の開発?というものにはほど遠い行き当たりばったりな計画と開発になってしまいました。

 

当時、先輩にこんな悩みを相談したところ、まずはCで流れを作ってから、開発するといいよ。と言われ、んなことねーだろとか思っていて自分から聞いておいて適当に聞き流したのですが、今回の開発ではなんとなくやってみようと思い、実際にやってみたら割と捗っています。

 

Modelが完成していなくてもとりあえずarray入れとくか、とかviewできてないけどとりあえずsetしておくか。みたいなノリでさくさくかけてよかったです。

あれ、悩んでなくね?っていう話なのですが、これでも結構悩んでます。

controllerは目に見えないところですので、結局効率よくdebugするためにはviewも作らなきゃいけない。っていう悩みがありますし。

 

大学時代に先輩がMVCのうち、膨大なC開発してどうしようもないことにならないように、Cのロジックを分割してS(Service)という概念を導入すると、違った視点で開発が出来て、こっちがあうケースもあるみたいなことを言っていた。

参考:http://www.objective-php.net/mvc/data

 

今回の開発には取り入れる事は不可能っぽいけど、ひとつの設計思想として覚えておこうと思う。

ただでさえ、馬鹿みたいなCがあって誰も改修したくないようなものがある部署なので、個人開発や新しい物の設計に置いては積極的に導入しようと思う