公司的 config 充斥著各種偶然。
Base Config 名稱打錯，但因為是動態載入，只要 production 的 config 名稱打對就可以運作。
但 production config 跟開發的 config 並沒有放在同一專案。所以我想也可能出現一種狀況是：有人在 dev 發現功能壞了，發現是 config 用錯，然後參考 base config 把 code 改成「正確」的 config 後心滿意足的送上 production，再把 production 炸掉。
還好現實事件中應該沒有發生這種狀況，目前只是會出現加了 base config 後沒在 production 加上對應的 config 而已~~ 小問題小問題
Base Config 名稱打錯，但因為是動態載入，只要 production 的 config 名稱打對就可以運作。
但 production config 跟開發的 config 並沒有放在同一專案。所以我想也可能出現一種狀況是：有人在 dev 發現功能壞了，發現是 config 用錯，然後參考 base config 把 code 改成「正確」的 config 後心滿意足的送上 production，再把 production 炸掉。
還好現實事件中應該沒有發生這種狀況，目前只是會出現加了 base config 後沒在 production 加上對應的 config 而已~~ 小問題小問題
至於為什麼會漏加，因為同一專案的 production config 也有五六份。
根據用途 (web api / worker / crontab) 就會 copy paste 出一份 87% 相同的新 config。改一個參數要記得不能漏掉任何一個 production config
根據用途 (web api / worker / crontab) 就會 copy paste 出一份 87% 相同的新 config。改一個參數要記得不能漏掉任何一個 production config
反正產品在 production 上可以動就好，也是有人跳過 base config，直接把東西加在 production config 上。至於開發嘛，有上線就代表能用啊 
為什麼有git了還會出現這種版本不一致的問題阿阿阿
瓜哥生日快樂 
生日快樂！
哇哇哇冬瓜さん生日快樂喔 
工作辛苦了！記得吃大餐犒賞自己喔！
工作辛苦了！記得吃大餐犒賞自己喔！
tcss0612: 也不是 git 問題。問題起源比較像是有超多 config 檔又散落在各處，然後程式碼也沒嚴格限制說只有有定義的 config 才能進來。所以就變成說這個變數在程式中沒定義，但 (production) runtime 還是會取得這個變數，所以不會炸。
tab按泰爽（？） w 