平屋慢生活

OCP 的價值甚麼? 又要改程式?回到 OCP 的精神怎麼做到？組裝電腦基因演化介面策略模式（Strategy Pattern）委派 / 函式注入（Func、Delegate）事件機制 / 觀察者模式（Event / Observer）組態驅動（Config-Driven）資料驅動（Data-Driven）插件架構（Plugin / 模組化 / MEF）管線（Pipeline） / 中介軟體（Middleware）Reference我們先來想一個問題：軟體服務與實體產品最大的差異是什麼？它的價值來自哪裡？ 一台車、一棟房子、一支手機，當它製造完成、出廠後，要再改動幾乎不可能。你或許可以維修或加裝零件，但「核心設計」已經固定。因為製造實體產品的成本主要在 生產鏈：模具、材料、工廠產線、物流。只要東西做出來，要大幅修改就得「重新開模 → 重做 → 巨大成本」。因此，實體產品通常必須在設計階段就「盡量定案」，避免後期修改。 而軟體完全不同。軟體的「製造成本」幾乎為零，複製一份就能立刻運行。它的價值不在於「做出來」，而在於是否持續符合需求。當需求變動，只要重新開發、部署，就能立刻改變行為。軟體 ...

還記得第一次接觸大型專案時的場景嗎？到處散落著不同的設定檔，有人用 JSON，有人用 XML，還有人直接在程式碼裡寫死一堆參數。結果要切換環境時，就像在拼一個缺角的拼圖：少一個值，系統就崩潰。 這就好比一場樂團演奏，每個樂手都拿著自己的譜，卻沒有人統一節拍。開發人員成了指揮，卻只能不停喊：「誰的設定跑掉了！」。 而 .NET Core 的 ConfigurationBuilder 就像是一個樂譜整理師，它把不同來源的設定集中起來，統一成一份總譜。無論是 JSON、環境變數，還是命令列參數，都能被收編進來，讓系統在啟動時就能「合奏」出正確的旋律。 ⚙️ .NET Core 組態（Configuration）.NET Core 非常依賴 Builder 模式，而「組態（Configuration）」就是其中一個代表性範例。 Configuration 系統就像一個「設定管理中心」，它把不同來源的設定（JSON 檔、環境變數、命令列參數…）集中起來，讓你用一致的方式讀取與管理。 ⚙️ ConfigurationBuilder 的角色在 .NET Core 裡，Configura ...

還記得第一次接觸大型專案時的場景嗎？到處散落著不同的設定檔，有人用 JSON，有人用 XML，還有人直接在程式碼裡寫死一堆參數。結果要切換環境時，就像在拼一個缺角的拼圖：少一個值，系統就崩潰。 這就好比一場樂團演奏，每個樂手都拿著自己的譜，卻沒有人統一節拍。開發人員成了指揮，卻只能不停喊：「誰的設定跑掉了！」。 而 .NET Core 的 ConfigurationBuilder 就像是一個樂譜整理師，它把不同來源的設定集中起來，統一成一份總譜。無論是 JSON、環境變數，還是命令列參數，都能被收編進來，讓系統在啟動時就能「合奏」出正確的旋律。 ⚙️ .NET Core 組態（Configuration）.NET Core 非常依賴 Builder 模式，而「組態（Configuration）」就是其中一個代表性範例。 Configuration 系統就像一個「設定管理中心」，它把不同來源的設定（JSON 檔、環境變數、命令列參數…）集中起來，讓你用一致的方式讀取與管理。 ⚙️ ConfigurationBuilder 的角色在 .NET Core 裡，Configura ...

這就像搬家時，把東西胡亂裝在箱子裡，搬到新家後才發現少了零件、找不到工具。而 Options Pattern，就像是給每個箱子都貼上清楚的標籤，還附上說明書，無論是開發、測試還是上線環境，都能安心打開箱子，拿到正確的東西。 Options Pattern 是把 appsettings.json 裡的設定資料，轉成一個 C# 類別，然後透過「依賴注入（DI）」的方式注入到你的服務中使用。 ⚙️ 編譯時類型檢查（Compile-time Type Checking）你把設定對應到一個 C# 類別，這代表你在編譯階段就能知道型別對不對，不是等到跑程式才發現爆炸。 12var smtpServer = Configuration["Email:SmtpServer"]; // 傳回 string，錯了也不會報錯var port = int.Parse(Configuration["Email:Port"]); // 如果 Port 是 null 或字串，這邊才會爆炸 Options Pattern 作法（強型別）： 12345678public cl ...

這就像搬家時，把東西胡亂裝在箱子裡，搬到新家後才發現少了零件、找不到工具。而 Options Pattern，就像是給每個箱子都貼上清楚的標籤，還附上說明書，無論是開發、測試還是上線環境，都能安心打開箱子，拿到正確的東西。 Options Pattern 是把 appsettings.json 裡的設定資料，轉成一個 C# 類別，然後透過「依賴注入（DI）」的方式注入到你的服務中使用。 ⚙️ 編譯時類型檢查（Compile-time Type Checking）你把設定對應到一個 C# 類別，這代表你在編譯階段就能知道型別對不對，不是等到跑程式才發現爆炸。 12var smtpServer = Configuration["Email:SmtpServer"]; // 傳回 string，錯了也不會報錯var port = int.Parse(Configuration["Email:Port"]); // 如果 Port 是 null 或字串，這邊才會爆炸 Options Pattern 作法（強型別）： 12345678public cl ...

「請問你們的開發流程？部門是如何互相溝通？」 這件事就是在問敏捷開發與跨部門的協作，這個就可以問出「超級多」東西。 首先是關於 PM 部分：是用什麼工具去管理專案？PM 會交代要做的工作。（都不需要 Task board ?????）現在那麼多專案管理軟體，jira, trello, clickup等等，不要再像原始人一樣用嘴巴派任務。 使用什麼工具來了解API 規格？最雷的大概是「打了就知道」，那種憑感覺開發真的很糟糕⋯⋯最差最差也要有 swagger, postman json，但也沒有很理想就是了。以我來說最理想要有文件，文件必須登載以下：URL, Method, Parameter, Response DTO Scheme, Error Type。最討厭看到貼了一個 Json example 跟我說這是他的 response ，連type, enum, 什麼都沒交代。 最後是QA：用什麼去管理 Issues?最少要有使用專案管理功能，最差用個 GitHub or Gitlab 的Issue board。通常 issue 卡片要交代 Bug ，通常要內容、圖片、復現步驟。絕對不 ...

https://vocus.cc/article/67fa5aeffd89780001cc79ef

讓團隊知道為什麼要做，這件事比較少，常常 kickoff 與 refine 可能一起開，且比較偏向就是指派的感覺而不是協作，團隊就是先接下來再討論怎麼做，且通常專案專案之間沒甚麼空隙，通常是直接案直接壓進 Sprint 讓 RD 知道這功能和 KPI、用戶痛點的關聯，會提升投入感。 >> 反正都是說 用戶想要 沒惹 不太會跟工程師確認認知上的 未知程度 費工程度 複雜程度

OverloadConsole.WriteLine()String.Format() 或 $"{value}"HttpClient.GetAsync(...) 重載Overload 是讓「使用者思維」與「開發者實作」分離Overload 幫助 API 適應成長需求（可擴展性）用 Overload 做「語意導向」的 API 設計（Intent-Driven Design）取代複雜參數物件或旗標（Flag）用在「動作不變，情境變化」的功能設計Anti - 語意模糊Anti - 過度 overloadAnti - 行為不一致，產生不可預期狀態結語 對使用 API 的開發者來說。當他們呼叫一個方法時，心中想的只是「我要讓它運作」，卻不希望因為情境稍有不同，就被迫學習一整套全新的操作方式。這就是 Overload（方法重載） 存在的理由，它讓同一個「旋律」能被多種方式演奏，保持一致性，同時降低學習與使用的心智負擔 我們平常在寫 Console.WriteLine() 的時候，可以丟 string、int、bool、甚至物件，對吧？因為每種型別印出來的方式不一定一樣，比如物件就會呼叫 ToStr ...

在資訊的天空裡，每一次請求都是一隻信鴿。它揹著我們的訊息，穿過纜線與路由器，飛往未知的彼端。 但如果我們只急著把字條塞進它的翅膀，信鴿或許能起飛，卻未必能安全抵達。它需要一個完整的「航行指令」：要飛向哪裡、攜帶什麼、如何證明身份、以何種姿態展現誠意。 HttpRequestMessage 就是這份航行指令。它讓我們能在雲端的長風中，為信使裝備地圖、護照與行李，確保訊息能準確無誤地抵達遠方。 📨 HttpRequestMessageHttpRequestMessage 的存在就是為了讓 HTTP 請求能「物件化」並且「延後執行」，這是一種「Command Pattern」的應用：          組好請求指令 → 再交給執行者 HttpClient → 再送出 這樣做的好處是： 請求可以先組好但晚點再送 可以重複使用或修改 可以做攔截、紀錄、包裝（例如透過 DelegatingHandler） HttpRequestMessage 是一個「請求的包裹」，你可以把它裝滿所有你要送 ...