第14回: マイグレーション管理 — DBスキーマの変更を「チームで安全に展開」する
開発者Aが users テーブルに phone カラムを手動で追加したが、開発者Bのローカルにはない——。本番にも忘れずに追加しなければならないが、手順書が存在しない——。
Year
開発者Aが users テーブルに phone カラムを手動で追加したが、開発者Bのローカルにはない——。本番にも忘れずに追加しなければならないが、手順書が存在しない——。
テスト環境では速かった検索クエリが、本番データが100万件になったときに突然遅くなる——。これはインデックスがないまま、DBが全レコードを先頭から順に読み込む「フルスキャン」をしているからです。
投稿一覧を取得したあと、各投稿の著者名を取得するためにループ内でまたクエリを実行する——。N件の投稿に対して「1+N」回クエリが発行され、データが増えるほど応答時間が急増します。
Aさんの口座から1000円引いたあと、Bさんへの加算処理でエラーが発生した——。処理をそのまま放置すると「Aさんの残高だけ減って、Bさんには届かない」という最悪の状態になります。
$price->amount = 2000; と書いたら、全く別の計算処理でも価格が変わっていた——。オブジェクトの状態が外から自由に変更できると、こうした意図しない副作用が起きます。
function createUser(array $data) — この引数の $data に何が入っているか、型チェックなしに分かりますか?
支払い方法が増えるたびに、コントローラや処理クラスで if ($type === ‘credit’) { $payment = new CreditPayment(); } を書き続けていませんか?