第14回: マイグレーション管理 — DBスキーマの変更を「チームで安全に展開」する
開発者Aが users テーブルに phone カラムを手動で追加したが、開発者Bのローカルにはない——。本番にも忘れずに追加しなければならないが、手順書が存在しない——。
Author
開発者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(); } を書き続けていませんか?
$stmt = $pdo->prepare(‘SELECT FROM users WHERE …’) をコントローラやサービスクラスの中に直接書くと、DB実装とビジネスロジックが密結合します。
注文完了後にメールを送る。さらにSlackに通知する。さらに在庫を更新する。さらに分析ログを記録する——。
ソートアルゴリズムを切り替えたい、送信方法を切り替えたい、価格計算ルールを切り替えたい——。こうした「処理を差し替えたい」要求は実務で頻繁に起きます。