昨日は色々あって寝たのが3時くらいで、今日は8:30起き。全然大学生みたいな生活習慣なんだけど、この３週間くらいが結構忙しかったからなのか、だいぶ体力がついた気がする（気のせい？）。

この流れで、ぼちぼち運動を始めようかなと思う。今月中に、チョコザップ契約するCar🚗

〜

今日も今日とてひたすらコードを書いていた。俺の作業自体は順調なのだけど、初期のチーム開発はタスクの分担がなかなか難しい。と言うのも、全員のスキルレベルが結構違うし、一人は実装スピードがかなり早くて、もう一人がかなりビギナーな感じ、そして俺が真ん中くらい。
俺の悪い癖は、少し気になるところがあるとすぐに調べたりしちゃうことで、それをやっているとなかなか作業が終わらないので、調べる時間と作業を進める時間をちゃんと分けることは意識的にやる必要がある（とはいえ、エンジニアの仕事は調べる言葉めちゃくちゃ多いので、それがまた難しい）。

内定者アルバイトでの開発では、機能単位での開発になるから、それぞれの作業範囲が被ることは基本的にないし、そういったことを気にせず実装していた。
今取り組んでいるチーム開発は０からの開発なので、綺麗に分担しようとしても、一定被りの範囲が出てしまう。失敗したのは、マイグレーションに詰まったせいで先にフロントviewの実装から入ったのだけど、そうすると、共通部分となるModelやRepositoryの部分が完成しないので、一旦は以下の考え方でタスクを分けることにした。

ModelーRepository は１セットで、同一人物が担当
ServiceーControllerーViewは１セットで同一人物が担当

ModelーRepositoryは基本的にテーブルに張り付いていると考えて、また、あるRepositoryが色々なServiceクラスから使用されることを考えて、ここはセットで作る。

逆にService、Controller、Viewは、Repositoryに記述した汎用的なメソッドを使う側として定義することにした。Modelはデータの振る舞いを記述するが、実用的な観点から、結局はテーブル定義にほとんど張り付いて一対一対応になる。これを解消するために、Entityみたいなクラスを定義して、データのまとまりに振る舞いを持たせるみたいなことをやっているところもあるが、実際にEntityがあって助かるケースってそんなにない（WEBアプリケーションはたいていがデータをどう見せるか、保存するかというところに収斂するので）から、まぁ基本的に冗長。

〜

順番が前後するが、アーキテクチャ構成としてはRepositoryパターンで、Repository、Service、Controller、Viewの４層構造を使用している。RepositoryパターンはDBとServiceのの間に挟んで、DB操作を抽象化してServiceクラスから使用できるようにすることが目的である。ただ、実際に抽象化できてるのかは結構微妙な気もする。結局、そこそこの規模のアプリケーション開発なら、DBに対するCRUDは都度都度増やせば十分な気もするし。。。

とはいえ、階層化の恩恵自体はたぶんあって、流石にServiceクラスからEloquentでDBを直に操作すると、Serviceクラスがてんこ盛りになる気もするから、こんな感じで良いのか。正直、悪いアーキテクチャと比較しないと良さがわからないのだが、、、

また、それに伴って、ORM不要論とかアクティブレコード不要論みたいな話もあり、（実際、Repositoryを使うならこいつらは基本的にいらないと思う）この問題については別途記事にしたい。

とにかく、Laravelは質の低い初心者のQiita記事や、プログラミングスクールが出している密度の低い記事など、情報が錯綜しているので、情報を取捨選択するための指針が何かしら必要。

〜