閒談軟體設計
36公開內容
這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。
全部內容
免費與付費
最新發佈優先
這篇文章探討了在軟體開發中的技術債可能來自哪些原因，以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇，提供了對於技術債的思考與建議，針對開發人員在需要做出無奈的技術決策時，提供了一些建議。此外，還提供了一些在做出技術決策時的方法，如保留抽象層和避免vendor lock-in。
今天來聊個最近很夯的主題 DDD，但不是 DDD 的本尊 Domain Driven Design，而是無所不在的 Database Driven Design，Database Driven Design 不是不好，只是你的模型容易變成貧血模型，邏輯都集中在 service 層等等。
有趣的是，Model 其實沒什麼嚴格的定義，所以每個人對 Model 的解讀也不盡相同，有人覺得資料怎麼儲存屬於 Model 的一部份 (受 ORM 工具的影響)，有人覺得工作流程 (workflow) 是 Model 的一部份，我個人也有自己的想法，而且隨專案的規模和特性，也不是總是一樣的。
起源是當時 Facebook 有篇文章討論不少人分不清楚上述二者的差別，當時寫了首部曲《閒談軟體設計：API Naming Style》，接著是《閒談軟體設計：內部函式庫》，但始終沒談到 library 和 framework 的差別，主要是沒有好的例子，這次這例子還蠻不錯的。
我自己偏好用 Repository 搭配 decorator 來管理 cache，而不是在 controller 層或是到處都有快取的邏輯，如果程式都是透過 Repository 更新資料，Repository 就會是一個不錯的地方更新快取，邏輯也就不會散亂在各處了。
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
最近隨著 FP 的流行，immutability 一直被提倡，物件有狀態，會被修改好像是一種惡，但真是如此？immutability 很好，但所謂的狀態就是會隨著操作變動，差別只在於變動發生在哪裡？
針對這議題，從 devOps 的角度看，團隊應抱有持續不斷地改進的精神，努力降低上版的風險，最後，哪一天上版就僅僅是風險控管的問題了。風險控管除了考量到損失，當然還要考慮到團隊要怎麼 on-call，on-call 的資源夠不夠應付上版後的突發狀況，才能做出適當的決策。
這文章來自網友在 在 Medium 上的留言 (有人幫忙想題目也挺不錯的)，問到：Singleton 對於好的架構來說是否能避免就避免呢？我簡單地回了一下我的想法 ，但 Singleton 其實很有趣，所以就寫篇文章來聊聊吧！
真的要符合 single responsibility，通常會得到很多很小的類別或是函式，各別完成一個小的功能，然後在某個地方被聚合起來完成一個使用案例 (use case)，而不是一個很大的類別，包山包海，然後最後變成一個狀態超複雜，超級難測試的類別。
