本文以創用 CC 姓名標示-非商業性-相同方式分享 4.0 國際授權釋出
讀者您好
2024 即將結束，感謝各位讀者陪伴本電子報度過今年，不管今年過的是好或是不好，祝福各位讀者來年平安健康，沒煩沒惱。
這一期就是 2024 年的最後一期，下一次見面就是新的一年了。祝福大家，明年見！
🔹Clay
Clay 是一款輕量級、高效能的 2D UI 排版函式庫，結合類似 Flexbox 的靈活佈局模型與 React 的聲明式語法，專為快速構建複雜、響應式介面設計。體積小無外部依賴，與 Wasm 相容，低記憶體開銷。
🔹Ghostty
Ghostty 是一款由 HashiCorp 創始人 Mitchell Hashimoto 撰寫的新式終端機，支援分頁、多視窗，使用原生 UI 設計以及 GPU 加速。
🔹Slidevjs
Slidevjs 是一個以網頁為基礎的簡報製作工具，使用者只要使用純文字 Markdown 製作，就可以完成內容精美的簡報。
🔸善用抽象設計
在軟體開發的過程中，常常遇到程式碼裡充滿許多看似「抽象」的設計。不過，並不是所有抽象都真的能把底層的複雜度藏起來。有些情況下，這些所謂的「抽象」只是多一層函式或介面，沒帶來實質的幫助，反而讓除錯和效能提升更棘手。如果這些「假抽象」越囤越多，整個系統的可讀性和維護成本就會跟著提高。
真正好的抽象，應該要把重複、繁瑣的細節包裹在裡頭，讓大家在使用時能免去不必要的煩惱。就像 TCP 一樣，我們幾乎不需要理會它底層的傳輸細節，因為它已經把不可靠的傳輸過程處理好了，提供了相對穩定、容易使用的介面。反之，如果某個「抽象」只是在原功能外再加一層呼叫或轉送，卻沒帶來新價值，那就只是在拉長開發者的理解時間，沒達到簡化系統的目的。
畢竟，抽象並不是毫無代價的，過多、過度設計的抽象層會增加系統的複雜度，也會拖累執行效能。所以，我們在考慮要不要引入某個抽象時，最好先想想它能不能真正藏住底層複雜度，並且替開發團隊帶來明顯的便利。要是發現它只是在增加層次而沒有什麼實際價值，那就只會讓之後的維護和改善更困難。
🔸降低認知負荷
在撰寫與維護程式碼時，不僅要面對開發本身的複雜度，還會因為額外的抽象設計或多層結構而增加理解難度。本篇文章把認知負荷分成「內在」（Intrinsic）和「外在」（Extraneous）兩種，強調前者難以避免，但後者可以透過合理的設計與簡化來減輕。如果一味追求架構理論或使用過多的語言功能，就會帶來不必要的理解障礙，需要謹慎評估其實際效益。
為了降低外在認知負荷，作者建議在程式實作時減少多餘的抽象與深層繼承，並盡量使用清晰的命名和精簡的方法或模組。作者特別提到所謂的「深模組」（deep module），也就是將內部複雜度隱藏在模組內部，對外提供簡單介面，讓維護者不用同時理解所有細節與複雜交互。這麼做可以幫助新進人員更快上手，也能提升專案的開發效率與程式碼的可讀性。
此外，作者提醒要正確理解 DDD（Domain-Driven Design）等理論的重點，應該聚焦在問題領域的溝通與分析，而不是盲目將程式架構弄得過於複雜。文章也建議讓初級開發者參與程式審查，藉此找出易造成困惑的程式碼區塊，並進一步改善整體的認知負荷。如此一來，整個團隊能在確保彈性的同時，減少理解成本，並真正把心力放在軟體開發本身的價值上。
以上就是本期的內容，喜歡的話請給❤️，分享或轉寄本電子報給有興趣的朋友。如果您有想要介紹的開源專案，也請來信與我們分享，或是在 X (前 Twitter) 留言給我們，感謝！