Hello World
ユウHelloWorld
ユウとりあえず現場で役に立ったものをつぶやいてみる・・・
ユウ特定のプロジェクトに依存しない、よいLaravelアプリケーションの構築方法について・・・
ユウまず、名前の付け方。これのやり方で効率というのが変わってくる。
参加しているプロジェクト、サービスが何に関連しているのか。
抽象的すぎると何のことかわかりずらいのでイメージしやすいように程よいところまで分割していく・・・
ユウあと、重要なのはモデル、つまりDBの設計。
テーブルをどのくらいの単位で細かく定義するかというのも大切。
大まかには
user, event テーブルがあって・・・それぞれにtypeが存在して・・・みたいなところから形を作っていく。
ユウ
ちょっと脱線して
zenn codingのチートシート懐かしい・・・
ユウ脱線ついでに仕事のやり方についてすこし。。。
効率的に仕事をするには、自分自身がハイパフォーマンスを発揮することも大切ですが、もっと簡単なのは仕事を抱え込まないこと。具体的には自分の抱えているタスクをできるだけ分割して可能であればほかのメンバーにも手伝ってもらう。
これをやるだけでもし自分の調子が悪くてもほかのメンバーに手伝ってもらうことでチーム全体としての効率は下がらないということになります。
ユウ文章で書くのもなかなか整理しづらいのでやはりイメージは図にしてみるのが一番ですね
ユウ良いDBだと思う条件
・似たような名前を持つテーブルが少ない。
・テーブル名とカラム名を見ただけでなんとなくどんなデータ構造があって、どういうステータスの遷移をするのかが想像できる。
ユウバックエンドとしては究極的にはDBの情報を読み取ってフロントエンドに返すというのが仕事の責任の一つだと思う。だから取得元のDBのテーブルの設計が分かりやすくなっているとそれだけバックエンドの仕事もやりやすくなる
ユウLaravelを現在のプロジェクトで使っているけど
Laravelを一から組み立てて作るのではなくてLaravelから派生したLaravel Novaとかのサービスを使って開発するトレンドが来るのかもしれない...
ユウ開発するときに困るのは、どうすればいいのかわからなくなったり迷ったりすること。
迷ったりして方向性がぶれたりすると、モチベーションも下がる。
あとモチベーションが下がったときには時間をもらって休息を取ることも必要。急いで仕上げようとすると結局は回り道になったりする。
で、開発するときに迷うときというのは全体像がわからなくなる時というのがあると思う。
自分が今開発しているところが全体のどのくらいまでできているのか、あとどれくらいで終わりそうなのか。
大きいシステムとかプロジェクトになればなるほどそういうことを感じることが難しくなってくる。
人というのは終わりのわからない作業に直面するとやっぱりどうしてもモチベーションは下がってしまうと思う。あとどれくらいで終わるのかとか全体的な進捗の具合を把握するというのはやっぱり大事なことだと思う。
ユウ今のプロジェクトは結構コードにある程度処理の集約を求めている。
そのためにすでに書いたコードに結構大きなリファクタリングをすることも結構あったりするのだけど。
他人の描いたコードをリファクタリングするのは、正直あまり気が進まないというか。。。
今まで動いていたコードに手を加えたことで動かなくなったり、そういう手戻りが発生するから
なるべく一度形になったものに手を加えることをせずに開発を進めていけないものかと考えたりする。