站長阿川 · 09月19日

` 區，放每個功能的前世

每個模組先做一個最小可執行版本，然後不要刪掉它。

我的專案有一批只在 local / dev / testing 註冊的路由：

/_poc/images        圖片上傳機制
/_poc/email-otp     Email OTP 登入流程
/_poc/emails        各類通知信預覽與試寄
/_poc/cart          購物車與計價
/_poc/checkout      結帳流程
/_poc/subscriptions 訂閱

每一個都是那個模組剛開發時的最小可執行版本。沒有設計、沒有樣式，一堆按鈕加上一堆 dd() 風格的輸出。

正式環境連路由都不存在。

為什麼不刪掉

做完正式版之後，大部分人會把這些東西刪掉，覺得是垃圾。

我留著，因為它同時是三個東西。

一、scratchpad。 開發新機制的時候，我不想在真正的結帳頁上試。/_poc/ 是一個可以亂搞的地方，不用管版面、不用管流程、不用管登入。

二、活文件。 想知道「圖片上傳機制怎麼用」，最快的方式是打開 /_poc/images，上傳一張、看它產生哪些尺寸、按刪除看它清掉什麼。比讀原始碼快，也比讀文件可信——因為文件會過期，而這個頁面會壞掉。

三、回歸驗證。 這是最有價值的一點。哪天通知信寄不出去了，你要怎麼確認是信件模板的問題、還是寄信設定的問題？打開 /_poc/emails，選一種信、按送出。用最短的路徑，測到最底層的機制。

跟單元測試的分工

有人會說：這些用測試寫不就好了？

不一樣。測試是驗證「邏輯對不對」，POC 頁面是驗證「整條路通不通」。寄信有沒有真的寄出去、圖片有沒有真的寫進硬碟、OTP 有沒有真的收到——這些你用測試 mock 掉之後，就什麼都沒驗到。

而且 POC 頁面是給人看的。新人接手的時候，你叫他打開 /_poc/，一個一個點過去，半小時就摸清楚這個系統有哪些機制。

兩條規矩

一、正式功能不准寫在 /_poc/。 那裡是實驗室，不是產線。功能成熟了就搬到正式路由，POC 版本留在原地當最小示範。

二、POC 壞掉要修。 它不是免洗的。壞掉通常代表底層機制真的被改壞了，那正是它存在的意義。

一句話

/_poc/ 是功能的前世。 留著它，你隨時可以回去看這個機制最單純的樣子。

站長阿川

⭐️ Shopify 網站開發服務（給品牌）
https://job.turn.tw/shopify-services

⭐️ 川川電商事務所（全客製電商開發服務）
https://chuanchuan.tw

⭐️ 台灣 Shopify 商家交流 LINE 群（非官方）
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ

⭐️ 台灣 Shopify 開發者 LINE 群（非官方）
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA

0個讚 0留言 3瀏覽

共有 0 則留言

登入之後發表留言

文字內容提供幾種功能：
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式

站長阿川

🏆 本月排行榜

🥇

站長阿川

📝45 💬1

643

評分標準：發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10

本數據每小時更新一次