不要用 migration

首先，最直接的方法，就是不要用 migration。

如果有人提出疑問，這時你可以開始炫耀自己過去的豐功偉業，談談自己之前做過多大的案子，那時候哪有什麼 migration 可以使用……等。

畢竟，過去沒有 migration，大家透過互傳 SQL schema 還是可以開發，沒問題的。

多功能 migration

舉例來說，你可以在一個 migration 內同時實作：

• 建立某資料表
• 建立其他關聯資料表的索引
• 寫入對應的 StoreProcedure 和 Trigger

這可以讓之後的工程在維護資料表的結構時，需要費盡心思才能找到對應的 migration 進行調整。

如果有同事提出問題，跟他解釋這是同一個需求之內的項目，所以應該算是一件事情。

模糊的名稱

模糊命名的威力在這裡又可以施展囉！

將所有的 migration 都命名為 migration 或者 migrate。

之後的工程只好每個 migration 進去看看裡面實際的修改是什麼，相信他在這一番追蹤之後，要嘛對整個專案的資料庫結構會瞭解的非常透徹，要嘛只好自認能力不足離職，也有可能兩者皆是。

只寫 up()

不要在 migration 裡面實作 down()。

即使不能 rollback，工程師還是可以透過刪掉整個資料庫然後 migrate 的方式進行開發。

沒有什麼讓維護的工程師 migrate 出錯之後，發現其中一個 migration 的 down() 實作內容是

/**
 * Reverse the migrations.
 *
 * @return void
 */
public function down()
{
    // 我不想寫這一段QQ
}

更能打擊維運工程師的士氣了。