事業グロース
オフショア関係なく、
事業部側が「制作側にどういう指示を出したらうまく作ってくれるんだろう」って思うことありますよね。
ないなら話が終わってしまうのである設定で行きます。
事業部から制作に依頼があるケースって・・
ぱっと思いつく範囲だと
こんな感じではないかなと思うんですよね
特にb2b2cのメディアやポータルの場合は近いものがあると思います。
このケースには、事業部の依頼の仕方に答えがあります。
この図の中で要件メモと書かせてもらったものが重要で、
本来は画面IDごとに画面定義図があり(ないなら作らないといけないですよ)
その画面定義ごとに用件を伝えていきます(本ブログはその書き方は割愛)
この用件メモをデータフローのCRUDと紐づけるんですね。
そうすると影響範囲も一目瞭然でわかり、
開発者がオフショアだったり、ディレクターが経験不足で全体を見通した用件を言えない場合でも品質の担保や影響範囲を調べることができる強力なソリューションとして使えます。
と、ここまでは事業部でできる精一杯のこと
ここからですが、
開発の範囲で品質を保つためにやらないといけないことがあります。
実際のコードを元にN+1の解消をしながら説明をしましょう。
そもそもN+1コードってわかりますか？
オフショアの代名詞(見つけたら即解雇のクソコード)N+1コードです。
前回のコードの中に堂々とN+1コードがあったため
修正していきます。
そもそもN+1コードとは
リレーション先のデータを持ってくるとき、
そのリレーション元のデータがforeachでN回回って取得されている状態で、
foreachの中でさらにそのリレーションの情報をとるためにsql叩いている状態。
データもってこいという一回とN回回ってる中で実行されるsqlがあるため、
N+1回実行されることからN+1問題と言われます。
10回回すコードなら1回で済むsql文なのに、11回回してしまうクソコードです。
.envに
APP_DEBUG=trueを記載すると
実際に実行されてるsqlがN+1かどうかもわかるので、
確認してみましょう。
というよりも
前回のコードのように、
foreachの中でBelogToのモデルを持ってきてるものは全部N+1なので、
慣れてくるとレビューですぐにわかるようになると思います。。
今は実行すると
$like->jobと実行した時にN+1となるので、
return KeptJob::where('user_id', $userId)->get();
↓
return KeptJob::where('user_id', $userId)->with('job')->get();
で、解消されます。
ただ、jobの先で、jobとnurseryもN+1の関係があるので、
それを解消するために
return KeptJob::where('user_id', $userId)->with('job.nursery')->get();
にするのが正しいです。
さらに、nurseryの先でも
$likeJob->job->nursery->facilityTypes $likeJob->job->nursery->prefecture $likeJob->job->nursery->city
がN+1なので、
return KeptJob::where('user_id', $userId)->with([
'job',
'job.nursery',
'job.nursery.facilityTypes',
'job.nursery.prefecture',
'job.nursery.city'
])->get();
にするのが正しいです。
これで実行するとwhere inの形になってるのがわかります。
これで解消されました。
オフショアに関しては、
pluk使うこと
DRYコードを意識
N+1を使わない
service repogitoryデザインパターンを徹底する
そして前回のenumを使う
これでだいぶ綺麗になるのではないかと思います。
_____
こんにちは突然のだいきです。
オフショアはいいとして
日本人の場合は
下記をベースに基準を設けると良いと思います。
以上です。
CRUDとコードルールがしっかりしていれば
オフショアでもそれなりにしっかり開発ができます。
