鴨咪仔
我今天看了為什麼要用 .env
鴨咪仔
我覺得真正的理由是這樣不會用 git 的人如果用了 git add * 之類的, 不會把 .env 加進去
鴨咪仔
不然我實在是想不出到底差在哪裡 XD
鴨咪仔
還不都是 config....
香煎鰈仙喋喋不休
Python 流行用 .env 放設定參數我也覺得是不大理性的選擇,而且 Python 自己本身就有讀 .ini config 的 module (configparser)

使用 .env (宣稱)的主要理由是 env variable 在每個作業系統上都通用,但 JSON 啊 YAML 啊 INI 啊難道就真的沒那麼通用嗎(XML 表示:)?確實是有不同實作或平台的 parser 行為不一致的問題( Ref ),但幾乎都要很極端的情況才會發生
香煎鰈仙喋喋不休
唸書時和系方合作的駐點工程師在介紹 git 時說「不要老是用 git add -A」,結果是如獲至寶往後開發到處用 git add -A,因為這樣做連 .gitignore 一類的 dot file 都不放過所以感到很滿意
[狼鼠]
那我沒跟上"流行" XDD, 我沒在專案中用.env ,倒是用node.js的同事在用XD
鴨咪仔
我就聽聽別人說然後查查資料
鴨咪仔
以前只有程式會 over design, 現在連架構都 over design XD
鴨咪仔
像是為了考慮以後如果用 k8s 管理 docker 那希望同一個 container image 可以改變角色所以設定檔的設計要 blah blah blah
鴨咪仔
等到有用 k8s 再來調整這些東西還來的及吧 XD
鴨咪仔
先專注在讓現在開發起來比較輕鬆怎麼樣? XD
鴨咪仔
之前做了個 library 就跟人討論了一下其他 project 要怎麼加進去比較好
鴨咪仔
1. submodule 2. 放 release 檔案
鴨咪仔
然後我也不知道怎樣是比較好的方法, 所以就放置什麼都不做 XD
鴨咪仔
結果過了幾天, 因為出了一些狀況, 馬上決定用方法 2 XD
鴨咪仔
大家也一致同意方法 2 比較安全, 後來花了一天寫 script 自動把 library 包好跟發布 release XD
鴨咪仔
這樣不是很好嗎... 花大把時間設計了一堆結果最後真的需要的時候不適用還不是一樣要改 XD
[狼鼠]
我也是偏這派的…當然如果已經有同類專案很有經驗,有些東西做單純或某種設計就會依狀況直接選擇。但這有點難拿捏,有的人是先做了初期方便用的版本,但沒有在適當的時機修改成未來適合的方案,造成未來的嚴重負債;有的是(也沒什麼經驗,但看了偉大的方法論書籍)以為要一次到位才是技術與世界接軌,結果99%都 over design,還不知道問題在哪,只是為了用而用…
[狼鼠]
但我一律說我不懂,所以先做可以用的版本,但留後路再來更迭,然後過程就可以偷學 XD
鴨咪仔
啊... 這是我遇到的另外一個狀況 XD
鴨咪仔
開發方法是來協助開發流程變順暢的, 不是自己要改變很多好去 fit 開發方法的, 不要削足適履啊
鴨咪仔
遇到覺得不順的情況, 要好好的思考不順的原因到底是沒有落實方法, 還是開發流程有根本性的不合適的地方
香煎鰈仙喋喋不休
因為大家都在講 SOLID所以就去看鄉民對 Clean Code 的評論結果翻到一堆負評 覺得開心

這書被批說裡面範例程式碼即使是以 N 年前舊版 Java 的標準也是廢到起笑甚至處處違反自己寫的設計原則
鴨咪仔
[狼鼠] : 沒經驗覺得技術要與世界接軌然後 over design 好像也是一種 pattern XD
載入新的回覆