現在已經蠻習慣開發時先寫測試，不過怎樣寫好的測試案例還是之後需要思考的問題。除此之外 Ruby 的 Cucumber 預設值其實非常完善，使用起來是我在不同語言使用經驗中最好用的 XD

驗收測試 - 重新思考 Rails 架構

工作好幾年，第一次覺得該為了休息而請假一週（剛好手邊一些事情告一段落）

今天第一天，開心吃完早午餐回家開始看新番，到晚上後開始進入「明天好像可以來寫程式」的狀態了

要怎麼去切分到現在還是很猶豫，即使看起來合理也會在一些比較特殊的情境上遇到問題。同時要去找到一些容易區分的規則又需要不少實驗，即使現在還是很容易在初期切分過多而需要退回來一些⋯⋯

架構規劃 - 重新思考 Rails 架構

要分清楚也不算容易，一個物件會隨時間增加越來越多功能，就可能出現過多職責的狀況。因此經常重構拆分或者組合是很常見的，這也讓區分職責變得更困難，需要判斷當下怎樣的範圍是相對恰當。

職責劃分 - 重新思考 Rails 架構

現在依舊還是覺得去找邊界很難，比較多情境會是跟實際需求有關，所以要釐清就會比較花時間，不太會是單純靠技術相關知識可以推理的。

劃分邊界 - 重新思考 Rails 架構

@dildogaggins - 做了個網站 - 查詢台北fine dining餐廳的最新訂位空檔和價位
壞消息：很難訂
好消息：吃不起

有時候晾衣服的陽台會聞到煙味，大樓也公告很多次還是不時會有

但今天變成泡麵的香味到底是什麼狀況，不能在家裡吃嗎？？

Release v4.0.0 · cedar-policy/cedar
中秋節出大改版，這是讓我要花整天更新我實作的 Ruby Binding 嗎 QQ

文章寫完後來也有拿 ChatGPT 之類的搭配 CoT 這類技巧透過提問、思考、反思、解答的流程來輔助探索，得出的結論跟目前思考的方向還是蠻接近的。

不過也有一些其他的疑慮，也許還要花一些時間多看各種案例來判斷哪種方式更適合 🤔

論 Use Case 和 Domain Service 的差異

以前蠻常會寫到一半覺得「好像可以重複使用這段程式碼」然後就開始改，後來累積不少經驗後，會發現先讓他重複，等到真的有跡象再改也不遲。某方面來說也是因為習慣寫測試，假設已知（測試過）是正確的，那麼重構後只要能通過測試就沒問題。

重復使用的反思 - 重新思考 Rails 架構