能載舟，能覆舟

前幾篇似乎說了很多 Rails 的壞話，但其實 Rails 是一套工具，工具沒有好壞之分，只有是否適合、怎麼使用。Rails 最重要的設計理念是 慣例優先於設定──很多事都幫先幫你做好了，這些慣例不一定適用在所有專案，但在發展初期不會有大影響──這種特色可以在短時間內快速的建立網頁應用程式，因此特別適合新創公司，用來迅速驗證新興商業模式、並應對時時變動的需求。

當專案開始成長，漸漸會需要許多客製化的設定和設計，然而一開始使用的慣例會產生一股慣性，這樣的慣性會使專案很難再去調整，因此也就會使整個專案漸漸的腐化。

至此對 Rails 的特性的介紹，提供作為了解後續奮鬥史的背景參考。接著呈現，在一切奮鬥的開端，團隊如何意識到「嗯？好像不太對勁？」，以及仔細檢視後挖掘出的潛在問題。

病識感

身為開發者，需要評估開發某個需求的時長，在開發完後檢討預估時間和實際開發時間是否相符；其中觀察到，實際開發時間都會比預估時間多，表示有某個環節出問題，於是開始尋找流程中花最多時間處理什麼事。

仔細檢討後發現，花了最多時間在測試，檢查新功能的運作、以及保證其他原有功能不被影響，而前述「測試」大多是在 local 跑 server 後去操作網頁，流程非常沒有效率，執行速度很慢、沒辦法時時刻刻執行，還需要去資料庫建立理想中的測試資料。

既然如此，補測試來取代手動測試是不是就能解決問題了呢?
但事實卻是，當我們關注到測試的品質與涵蓋範圍，著手寫新測試，卻發現比寫新功能還難，同時意識到舊有的測試並不有效，原因有以下幾點：

• 大部分舊有測試是測頁面上的文字
  頁面上的文字常會因為行銷需求需要不同論述而做調整，也沒辦法測出底下的業務邏輯是否有正常運行，因此被我們視為無效測試，沒有繼續維護。

• 每個測試都需要處理大量 association 關係
  假設 DB 中有限制每張訂單 Order 都會需要有對應的 Customer

  為了維持資料正確性會在 DB 上加上許多 constraint

  這時候所有有關 Order 的測試，在建立測資時就必須連同 Customer 一起建立，然而並不是所有 Order 的操作都會跟 Customer 有關係。這導致需要花很多時間去處理不相關的測資，除此之外執行測試的時間也會延長許多。

  另一種作法是把 Order 整個 mock 掉，但這種做法有高機率連同新寫的邏輯一起 mock 掉

• 寫在 view 和 controller 的邏輯難測試
  如果要在這些地方做測試，需要載入整個專案並把 server 跑起來，這樣的測試已經不是 unit test ，執行需要花很多時間間接導致開發時間延長。開發時都會用手動檢查(在本地端開server 跑看看)取代這樣的測試

下一篇終於要開始描述我們如何面對這些問題，並述說我們所做的決定和每一步。

這些走過的路不一定是最短的路，也不一定會是最好的決策，是我們在有限的時間和人力資源下所做的決定，因此後續的篇章會比較偏向分享心得，而不是針對上述問題的解答。