平屋慢生活

🪵 降低耦合購物車維護物件的不變性-遊戲角色PropertyProperty and Field所謂「降低耦合」，就是讓物件的使用者能很直覺地透過公開的方法去操作，而不用關心內部的細節。這麼做有兩個好處 使用者能專注在更高層次的抽象，而不是陷在物件內部的實作 後續如果內部邏輯要修改，開發者比較不用擔心會影響到外部程式 12345678public class ShoppingCart{ public List<string> Items = new List<string>();}var cart = new ShoppingCart();cart.Items.Add("iPhone");cart.Items.Clear(); // 嘿嘿，使用者直接把購物車清空 如果直接把集合公開，外部程式就能為所欲為： 隨便新增重複的商品、甚至一次把所有商品刪光，這樣一來，我們完全無法控制購物車的正確狀態 透過封裝，我們只提供必要的方法 123456789101112public class ShoppingCar ...

為什麼需要「分頁」當資料量很多時，一次全部載入會出現幾個問題： 傳輸時間變久（效能差） 前端渲染太慢（使用者體驗差） 資料可能會更新（你讀到的資料其實過時了） Server 壓力大（記憶體吃光、CPU 爆掉） 所以我們會把資料「一頁一頁」傳給前端，這就叫做 分頁（Pagination）。 Offset/Limit 分頁用 OFFSET 跳過前幾筆資料，用 LIMIT 限制要拿幾筆。 123456789-- 假設每頁 10 筆-- 第1頁SELECT * FROM Products ORDER BY Id LIMIT 10 OFFSET 0;-- 第2頁SELECT * FROM Products ORDER BY Id LIMIT 10 OFFSET 10;-- 第3頁SELECT * FROM Products ORDER BY Id LIMIT 10 OFFSET 20; 問題一：效能差（尤其當 OFFSET 很大時） 就像你去圖書館要看第 10000 頁的書，圖書館員還是要翻過前面 9999 頁才能給你第 10000 頁。資料庫也是一樣，它要先讀取前面 9999 ...

組件（Assembly）internal 想解決的問題Helper 或 Utility 類別大型專案結構的流程物件測試專用 Stub 或 Mock classFactory 或 Builder 的內部部件summary在 .NET 中，「組件（Assembly）」是一個可以被執行或被載入的最小單位，通常就是一個 .dll（類別庫） 或 .exe（應用程式執行檔）。 Dynamic Link Library（動態連結程式庫）。它是一個 二進位檔（binary file），副檔名是 .dll。裡面存放的是「程式碼 + 資源」，但不能自己執行。要靠其他程式（例如 exe）來「載入」它，才能使用裡面的功能。簡單說，DLL 就像一本工具書，裡面有很多函式與類別，你可以引用它，但它不會自己動 在 Windows 下，DLL/EXE 都遵循 PE（Portable Executable）格式。.NET 世界裡，DLL 裡面會多一層 IL（Intermediate Language，中間語言） 和 Metadata（中繼資料）。也就是說，.NET 的 DLL 並不是直接的 CPU 機器 ...

法律對開發者的具體好處summary工具 / Helper / Utility 類別邏輯封閉、不可更改的業務邏輯類別安全性/授權處理類別小型不可變物件（Immutable Value Object）專案 SDK / Library 對外的「黑盒類別」專案 SDK / Library 對外的「黑盒類別」法律是一個經過設計的系統，不能隨意被改寫、繼承或覆蓋。你不能說：「我繼承《交通法》，然後 override 掉超速罰則。」就算你覺得這條法律不合理，也不能自己改動，只能在法律框架下使用它。 法律是 sealed 的。因為它必須保證一致性、可預測性、公平性。若人人都能繼承、改寫，那麼整個社會將陷入混亂 同樣地，一位資深醫生制定的手術流程極為嚴謹有效。新人不能說：「我繼承這個流程，但不消毒就直接開刀。」這就是為什麼醫療 SOP 是 sealed ，當一個系統至關重要、不能容許錯誤時，它就應該被封印 sealed 的意義在於：在自由與彈性之中，劃下一條「不可更動」的底線，以確保核心價值的穩定與安全。 對系統來說：是一種 封裝 對團隊來說：是一種 約束 對使用者來說：是一種 ...

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 ，通常要內容、圖片、復現步驟。絕對不 ...