🌘 何時人們傾向於組合而非繼承？
➤ 追溯軟體設計名言的起源與演變
✤ https://www.sicpers.info/2025/11/when-did-people-favor-composition-over-inheritance/
這篇文章探討了「傾向組合而非繼承」這句軟體設計名言的起源與深層含義。作者追溯了此觀點在《設計模式》一書中的出處，並分析了早期物件導向語言（如 Smalltalk）與較新語言（如 Java）在封裝和存取權限上的差異。文章闡述了繼承的「白盒」重用方式（編譯時期綁定，較難更改）與組合的「黑盒」重用方式（執行時期綁定，易於更改）的區別，並指出組合能提供更高的彈性，允許在執行時期更換物件行為。同時，文章也結合了 Liskov 和 Wing 提出的子類型關係概念，探討了為何組合能讓設計者在不拘泥於嚴格的類型層級下實現多型。最後，作者也提及了其他替代方案，如使用一等公民的程序（如 Lambda 函數），指出「組合優於繼承」並非唯一解。
+ 這篇文章的分析很到位，終於理解了這句口號背後的歷史脈絡和技術考量。
+ 感謝作者點出「組合優於繼承」並非萬靈
#軟體設計

🌘 未來終端機：重新想像 200 年後的電腦介面
➤ 從 Jupyter 的啟發到分階段的建構藍圖
✤ https://jyn.dev/the-terminal-of-the-future
本文探討了現有終端機的限制，並展望了未來 200 年的電腦介面。作者透過對比 Jupyter Notebook 的優勢，提出瞭解決傳統終端機在互動性、狀態管理和持久性方面的問題。文章詳細闡述了實現更優終端機的技術細節，包括 shell 整合、長程進程處理、中斷與恢復、以及持久化會話等，並提出了分階段的建構藍圖，旨在打造一個更強大、更靈活的計算機互動體驗。
+ 這篇文章深入探討了終端機的演進潛力，期待看到這樣的未來！
+ 太棒了！終於有人點出傳統終端機的痛點，而且還提出了具體可行的解決方案。
#終端機 #軟體設計 #介面革新

🌗 為易腐敗事物設計的軟體
➤ 從香腸到代碼：打造有彈性的食品安全監控系統
✤ https://drobinin.com/posts/designing-software-for-things-that-rot/
本文作者分享他如何為容易腐敗的食材（如香腸、起司等）設計軟體監控系統。他從個人發酵的經驗出發，意識到追蹤數據不足以確保安全，必須結合食品安全框架HACCP，建立決策樹，將監控轉化為有意義的洞察。作者利用Home Assistant蒐集溫濕度數據，並編寫iOS應用程式來管理發酵過程中的各種「限制條件」（如pH值、濕度、重量損失等），這些條件會隨著發酵階段的推進而變化。最終目標是建立一個具備「可追溯性」的系統，而非僅追求數據的精確度，確保食品安全並能在出現問題時提供完整記錄。
+ 這篇文章的觀點很有啟發性！我之前也遇過類似的問題，覺得光是記錄數據根本不夠。HACCP的思路確實是關鍵。
+ 作者將開發者的思維應用在發酵上，真是太酷了！特別是那個決策樹的設計，很有條理。
#軟體設計 #食品安全 #發酵 #物聯網 #HAACP

🌗 驚嘆不再：蘋果發表會的失落感
➤ 從驚嘆到無奈：蘋果發表會洩漏的時代變遷
✤ https://morrick.me/archives/10137
作者 Riccardo Mori 在觀看蘋果的年度新品發表會後，對蘋果近年來的產品策略和設計方向感到失望。他認為蘋果已失去其獨特性，變得與其他科技巨頭相似，尤其在軟體介面設計上，過度簡化導致功能退化，無法體現 Steve Jobs 對「設計即功能」的理念。對於 Apple Watch 的生平故事展示和 AirPods 的環保問題，他也提出了質疑。在 iPhone 部分，作者認為新款 iPhone 的定位區分雖有助於消費者選擇，但 Pro 型號的定價過高，而 iPhone Air 的市場前景則令人擔憂。
+ 身為長期蘋果用戶，我感同身受！近年來蘋果的創新力確實不如以往，很多設計決策讓人費解。
+ 這篇文章點出了許多人心中的疑慮，特別是關於軟體設計的簡化和產品定價的問題。期待蘋果能找回初衷。
#科技 #蘋果 #iPhone #Apple Watch #AirPods #軟體設計 #消費性電子

🌘 為何軟體開發者鍾愛複雜性？
➤ 從行銷誘因到內在動機：解析軟體開發者對複雜性的迷戀
✤ https://kyrylo.org/software/2025/08/21/why-do-software-developers-love-complexity.html
文章探討了軟體開發者為何經常被複雜性吸引，即使「保持簡單」是眾所周知的原則。作者從行銷角度分析，指出複雜的產品更容易引起注意和被視為「高級」，並比較了「Penzilla」與「cat command」的例子。此外，作者也深入分析了開發者內在的動機，包括創造的誘惑、技術債、團隊協作以及創新的壓力，這些都可能導致過度工程化。最後，文章呼籲開發者應以埃及金字塔為鑑，建立有明確目的、堅實基礎且有實際價值的系統，而非徒具形式的複雜結構。
+ 這篇文章一針見血！我經常在工作中看到為了炫技而引入不必要的複雜性，卻忽略了維護的成本。確實，有時候簡單纔是王道。
+ 很有趣的觀點，尤其是從行銷的角度來解釋。'Complexity signals effort, expertise, and
#軟體開發 #軟體設計 #複雜性 #簡潔性 #行銷學

🌘 個人知識管理工具需提升資訊再喚醒功能
➤ 為何你的筆記應用程式讓你遺忘比記得更多？
✤ https://ankursethi.com/blog/pkm-apps-need-to-get-better-at-resurfacing-information/
作者認為現今的個人知識管理（PKM）應用程式在幫助使用者重新接觸已儲存但遺忘的資訊方面做得不夠好。他主張 PKM 工具應具備自動喚醒相關資訊的功能，如同 Spotify 的推薦機制，以提升資訊的利用價值，防止知識庫淪為資訊的墳墓。作者分享了自行開發的簡單工具來實現此功能，但強調這類功能應內建於軟體中，而非依賴外部擴充。
+ 說得太對了！我的 Obsidian 也是一樣，好多筆記都躺在那裡睡大覺。Spotify 的推薦確實是個好榜樣，希望 PKM 工具開發者能聽到這個聲音。
+ 作者自己動手做的 StumbleDrop 和 StumbleWise 聽起來很有趣，但確實，這些功能如果能原生支援，使用者體驗會提升非常多。API 的質量問題也是個老生常談了。
#個人知識管理 #PKM #資訊管理 #軟體設計

🌘 結合物件導向與函式設計以促進重用
➤ 一種結合物件導向與函式設計的複合模式，以克服擴充性限制
✤ https://cs.brown.edu/~sk/Publications/Papers/Published/kff-synth-fp-oo/
許多問題需要遞迴定義的資料類型及一套操作這些資料的工具。隨著時間推移，這些問題會演變，導致程式設計師必須擴充工具組，或擴充資料類型並調整現有工具。理想情況下，這應該在不修改現有程式碼的情況下完成。然而，現行的程式設計策略無法同時支援這兩種擴充性：函式程式設計支援新增工具，而物件導向程式設計則支援新增工具或擴充資料集，但無法兩者兼顧。本文提出一種結合兩種方法的複合式設計模式，解決了這兩種設計策略間的衝突，並展示了此協議如何為支援類別系統的語言提出一套新的語言設施。
+ 這篇論文提出的複合設計模式聽起來很有意思，解決了長久以來物件導向與函式程式設計在擴充性上的取捨問題。期待能看到更多實際應用的例子。
+ 能夠在不修改現有程式碼的情況下同時支援資料類型和工具組的擴充，這確實是軟體工程的一大突破。希望作
#軟體設計,程式語言,物件導向,函式程式設計

🌘 「讓無效狀態無法被表示」原則的潛在弊端
➤ 為何過度嚴謹的設計限制可能適得其反
✤ https://www.seangoedecke.com/invalid-states/
作者認為，過度追求讓軟體模型無法表示無效狀態，可能反而阻礙未來的彈性和變更。他以狀態機、外鍵約束和 Protocol Buffers 的 required fields 為例，指出雖然這些原則有助於初期推理，但在面對現實世界的邊緣案例和變更需求時，過於嚴格的約束會導致系統難以維護和演進。他主張軟體應保持一定的彈性，允許部分非嚴格約束，以便應對不可預見的需求和維護操作。
+ 這篇文章觸及了設計中的一個常見兩難。我曾遇過類似狀況，為了符合嚴格的狀態機，開發團隊花費大量時間處理邊緣案例。
+ 作者的觀點很有啟發性。我過去一直秉持著讓無效狀態無法被表示，但現在開始思考，也許有些彈性對長期維護更有利。
#軟體設計

🌕 iPhone 鬧鐘時間選擇器：並非圓形，實為超長列表
➤ 顛覆你的認知：iPhone 時間選擇器背後的驚人真相
✤ https://old.reddit.com/r/interestingasfuck/comments/1n5lztw/the_time_picker_on_the_iphones_alarm_app_isnt/
這篇文章揭示了 iPhone 鬧鐘應用程式中時間選擇器的真實運作方式，指出其並非真正意義上的圓形介面，而是一個極長的垂直列表。作者透過實際操作發現，要從列表的頂端滑動到頂端需要數十次滑動，這與使用者直觀感受到的「圓形」旋轉輪盤有很大差異，進而探討了這種設計的潛在原因。
+ 哇，我從來沒想過這個問題，原來平常滑半天的操作是這個原因，真是太令人驚訝了！
+ 這也太耗費時間了吧，如果能做成真正的圓形輪盤，操作起來應該會更直觀有效率。
#科技 #使用者介面 #軟體設計

🌖 別讓布林值氾濫：更佳的資料模型與設計
➤ 淺談布林值應被取代的時機與方法
✤ https://ntietz.com/blog/that-boolean-should-probably-be-something-else/
本文探討在軟體開發中過度使用布林值（boolean）所帶來的潛在問題，作者認為絕大多數情況下，布林值應被更具表達力的資料類型取代，例如時間戳記（datetime）和列舉（enum）。透過將布林值轉換為適當的資料類型，不僅能儲存更豐富的資訊、提升程式碼的可讀性和可維護性，還能為未來系統擴充預留彈性。文章提供了具體的案例和建議，教導開發者如何辨識何時應避免使用布林值，以及何時其存在是合理的。
+ 寫得太好了！我常常在專案中看到一堆 `is_active`、`has_permission` 這類的布林欄位，看了就頭痛。這篇文章點出了問題核心，轉換成 enum 的確能讓狀態管理清晰很多。
+ 雖然我同意布林值有時會顯得不足，但文章中提到「幾乎每一次」都應被取代，這說法有點太絕對了吧？有些簡單的旗標（flag）用布林值
#軟體設計 #資料結構 #布林值 #枚舉 #資料庫

🌘 軟體大型設計的學問
➤ 掌握複雜度，打造可長久維護的軟體系統
✤ https://dafoster.net/articles/2025/07/22/designing-software-in-the-large/
這篇文章深入探討了《A Philosophy of Software Design》一書的核心觀念，強調軟體大型設計的關鍵在於有效管理系統的複雜度。作者指出，複雜度源於模組間的依賴和資訊的不明確，進而導致「變更放大」、「高認知負荷」和「未知未知」。為降低複雜度，文章建議建立「深度模組」，縮小介面，並避免重複、濫用例外和繼承。同時，文章也強調「顯眼」程式碼的重要性，透過清晰命名、一致風格和完善文件來減少「模糊性」。作者鼓勵採取「策略性」的開發心態，主動投資時間於優良設計和問題修復，而非僅追求功能實現，以確保軟體長期可維護性。
+ 非常受用！這篇文章精準地指出了許多開發者在大型專案中遇到的痛點，並提供了具體的解決方案。我尤其認同「零容忍」於複雜度累積的觀念。
+ 讀完這篇文章，我對「戰術性」和「策略性」的思維有了更深的體悟。
#軟體設計 #程式開發 #複雜度管理 #維護性

🌘 自我保障的承諾
➤ 如何辨識並選擇真正可靠的數位工具
✤ https://stephango.com/self-guarantee
本文探討「自我保障的承諾」這一概念，強調使用者無需信任第三方，即可自行驗證的承諾。作者以「檔案透過 App」和「不鏽鋼」為例，說明這種承諾的可靠性，並對比了 terms and policies、政府結構編碼、以及僅有開源的應用程式，指出後者可能因資料鎖定或公司營運變動而難以實現承諾。文章建議使用者在選擇工具時，優先考慮能做出自我保障承諾的產品，以應對未來的不確定性。
+ 這篇文章點出了許多使用者在數位時代所面臨的痛點。很高興看到有這樣的觀點，提醒我們不要輕易相信那些無法驗證的承諾。
+ 「自我保障的承諾」這個概念很有啟發性。確實，過去很多服務都以「信任」為基礎，但當公司政策變動或倒閉時，使用者往往是最大的受害者。
#軟體設計 #數位權利 #使用者信任

🌘 無尾熊對烏鴉：軟體演化的理論
➤ 從生物演化看軟體設計的兩種極端
✤ https://ajmoon.com/posts/koalas-vs-crows-an-evolutionary-theory-of-software
本文作者Alex Moon提出一個新穎的觀點，將生物演化的「無尾熊策略」與「烏鴉策略」類比於軟體開發。他認為，如同生物為了適應環境而選擇低能耗或高能耗的演化路徑，軟體也存在著兩種截然不同的設計哲學：一種是追求極致簡單易用（無尾熊軟體），另一種則是強調強大功能與彈性（烏鴉軟體）。作者透過舉例說明這兩種軟體類型，並探討其背後的演化壓力與適用場域，為理解軟體發展提供了獨特的視角。
+ 這個比喻太精妙了！終於有人能把複雜的軟體概念講得這麼淺顯易懂。
+ 很有啟發性，但我認為「無尾熊軟體」也需要高度的智慧才能設計得如此簡潔。
#軟體開發 #演化理論 #認知負荷 #軟體設計

🌘 具學習性的程式設計：打造一個理解程式的系統
➤ 跳脫死記硬背，讓程式語言的奧祕清晰可見
✤ https://worrydream.com/LearnableProgramming/
本文探討如何設計一套更具學習性的程式設計系統，以幫助人們真正理解程式而非僅是記憶語法。作者Bret Victor批評現有系統，例如Khan Academy的「即時編碼」環境，認為它們未能有效傳達程式的思維方式，也無法讓學習者看見程式的運作過程。他提出一套設計原則，強調環境應能讓學習者「讀懂詞彙」、「追蹤流程」、「看見狀態」、「透過反應創作」和「透過抽象化創作」，而程式語言則應提供「身分與隱喻」、「分解」、「重組」及「可讀性」。系統的重點不在於單一功能，而在於整體設計如何引導學習者思考。文中舉例說明如何透過滑鼠懸停標籤、程式碼與輸出連結等方式，讓程式的意義透明化，並強調理解程式運作的「步驟」遠比看到最終結果重要。
+ 這篇文章點出了程式學習的關鍵痛點，期待能有更多這樣的系統出現！
+ 作者的觀點很有啟發性，從使用者介面設計的角度來思考程式教學，真是前所未見
#程式設計 #教育 #使用者介面 #軟體設計

🌘 Folklore.org：計算器建構套件
➤ 追求完美：史蒂夫·喬布斯與麥金託電腦計算器的設計故事
✤ https://www.folklore.org/Calculator_Construction_Set.html
本文講述了蘋果早期員工克里斯·埃斯皮諾薩為麥金託電腦設計計算器的故事。他最初的設計未能獲得史蒂夫·喬布斯的認可，不斷受到批評。最終，克里斯靈機一動，創造了一個可自定義參數的“史蒂夫·喬布斯自製計算器建構套件”，讓史蒂夫·喬布斯得以自行調整，最終設計成為麥金託電腦標準計算器，並沿用至OS 9。
+ 史蒂夫·喬布斯對細節的執著真是令人印象深刻，連計算器都要親自調整！
+ 這個故事很有趣，讓人瞭解到蘋果早期設計的過程，以及史蒂夫·喬布斯在其中的角色。
#蘋果歷史 #軟體設計 #史蒂夫·喬布斯

🌕 是否應為不穩定的網路環境設計？
➤ 低頻寬時代的軟體設計考量
✤ https://bytes.zone/posts/should-we-design-for-iffy-internet/
這篇文章探討了美國網路普及率及連線品質的問題，指出即使在2025年，仍有部分地區的居民無法享有穩定且快速的網路服務。作者分析了聯邦通訊委員會（FCC）和國家教育統計中心（NCES）的數據，顯示約有3%的美國家庭網路連線速度低於25Mbps下載及3Mbps上傳，且延遲可能較高。文章強調，軟體開發者在設計應用程式時，不應過度假設使用者擁有優質網路環境，特別是針對B2C產品，應考量低頻寬及流量限制的使用者需求。此外，文章也提及學生網路普及率的數據，顯示低收入家庭的網路普及率仍然偏低。
+ 很有趣的數據分析，讓我意識到網路環境對使用者體驗的重要性。原來連線品質的差距這麼大！
+ 這篇文章提醒我，在設計手機應用程式時，要特別注意流量的使用，避免使用者因為網路速度慢而感到不便。
#網路基礎設施 #軟體設計 #使用者體驗

🌕 《可塑軟體：在封閉應用程式的世界中重拾用戶自主權》
➤ 從工業化量產軟體邁向使用者主導的數位工藝革命
✤ https://www.inkandswitch.com/essay/malleable-software/
本文探討當代軟體僵化問題，主張開發可讓用戶自由重塑的「可塑軟體」，重現個人運算原始承諾。
+ 終於有人說出心聲！每次為遷就軟體修改工作流程都覺得本末倒置
+ 理想很豐滿，但安全性和技術門檻如何解決？普通用戶真能駕馭可塑軟體嗎？
##科技創新 #軟體設計 #用戶賦權

🌕 蘋果推出令人驚豔且優雅的新軟體設計
➤ Liquid Glass：打造流動且引人入勝的使用者體驗
✤ https://www.apple.com/newsroom/2025/06/apple-introduces-a-delightful-and-elegant-new-software-design/
蘋果公司預覽了全新的軟體設計，運用名為「Liquid Glass」的新材質，為應用程式和系統體驗帶來更豐富的表現力與愉悅感。此設計將跨足 iOS 26、iPadOS 26、macOS Tahoe 26、watchOS 26 和 tvOS 26 等平臺，在保持各平臺獨特之處的同時，實現更和諧的統一。Liquid Glass 材質具有半透明特性，能根據周圍環境和內容動態變化，提升使用者介面的活力，並使互動更加直觀和流暢。
+ 蘋果的設計一直很領先，這次的Liquid Glass概念真的很有意思，期待實際使用起來的效果！
+ 跨平臺統一設計是個好趨勢，希望這次的更新能帶來更一致的使用體驗。
#蘋果 #軟體設計 #Liquid Glass #iOS 26 #macOS Tahoe 26

🌕 設計壓力
➤ 隱形之手塑造你的程式碼
✤ https://hynek.me/talks/design-pressure/
這篇文章探討了軟體設計中難以察覺的潛在問題，即使遵循最佳實踐，專案架構仍可能變得複雜。作者Hynek Schlawack分享了他在PyCon US 2025的演講內容及相關參考資料，涵蓋了耦合、物件導向設計、領域驅動設計、測試以及API設計等面向。核心觀點在於，軟體設計涉及許多權衡取捨，需要意識到不同類型的類別和模型的差異，並避免過度簡化問題。
+ 這篇文章提醒我，即使有經驗的開發者也需要不斷反思自己的設計，避免陷入不必要的複雜性。
+ 推薦書單和影片列表非常有價值，可以幫助我更全面地瞭解軟體設計的各個方面。
#軟體設計

🌗 PuTTY 工具圖示研究
➤ PuTTY圖示的歷史與演變
✤ https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/putty-icons/
本文回顧PuTTY工具的圖示設計歷程，探討其起源及演變過程，涵蓋了從手繪時代到腳本化時代的各個工具圖示設計，包括PuTTY、PSCP、PSFTP和Pageant等工具的圖標變化。
+ 這篇文章真有趣，讓我瞭解了這個廣為使用工具的背後故事！
+ 這麼多年的演變真讓人驚訝，設計選擇也很有意思，尤其是為什麼電腦顯示器是藍色的！
#軟體設計