資料庫砍掉重建是日常操作,不是災難。
我對專案的一個硬性要求:任何時候、任何人,執行這一行都要能得到一個完整可用的系統。
php artisan migrate:fresh --seed
砍光資料表、重建、塞資料。三十秒後,你有商品、有分類、有促銷設定、有運費設定、有點數方案、有橫幅、有公告、有測試帳號。打開網站可以逛、可以加購物車、可以結帳。
新人 onboard 從一天變成十分鐘。 clone、composer install、migrate:fresh --seed,開始工作。不需要跟人要一份 SQL dump,不需要問「為什麼我的首頁是空的」。
你敢改 migration。 如果重建資料庫是一件可怕的事,你就會開始累積「補丁式」的 migration——加一個欄位、改一個欄位、又改回來。因為沒人敢重來。能隨時重建的話,開發階段的 schema 可以一直保持乾淨。
你敢改壞東西。 本機資料改爛了?重建就好。這會讓你更願意做實驗。
這是這個要求的真正成本。每加一個模組,就要補對應的 seeder。
很多團隊做不到這件事,是因為 seeder 寫了一次就沒再更新,半年後跑起來會噴錯,於是大家改用「跟同事要一份資料庫」——然後就再也回不去了。
我把它當成模組完成的定義之一:功能沒有 seeder,就不算做完。
其中最關鍵的是設定類的 seeder。因為我的 Setting::get() 缺 key 會直接拋例外,沒有 SettingSeeder,網站連首頁都打不開。這是好事——它強迫 seeder 必須是最新的,不然你自己第一個會發現。
新人想知道「商品模組需要哪些資料才能運作」,最快的方法不是讀 migration,是讀 ProductSeeder。
migration 告訴你有哪些欄位,seeder 告訴你這些欄位實際上長什麼樣。 後者有用得多。