ExplainThis 全端開發雙週報 #19

2024 前端框架趨勢預測、節約架構 (The Frugal Architect) 的七大原則、DHH 談能力養成

本期是 2024 年的第一期雙週報，很高興在 2024 年也能持續透過雙週報，與大家分享前端、後端，以及職涯的大小事。

在進到本期的內容前，想先感謝目前已經訂閱 E+ 的九十多位讀者。在 2023 年最後一期雙週報與大家分享 E+ 後，陸續有讀者訂閱，而 ExplainThis 團隊也馬不停蹄地在把我們過去的內容、模板、資源等做更完善的整理。

目前已經確定 E+ 在 2024 年的深度內容，會由前端系統設計、後端系統設計、邁向資深的軟體工程須知，以及成為高效工程師四大主題每週輪流進行。除此之外，我們也正在整理完整的求職全攻略、各類好用模板，讓讀者們在求職與工作上都能更高效。

目前 E+ 的盲鳥倒數一週，在 1/21 前使用 BLIND66，都可享有終身 66 折訂閱優惠；期待 1/22 後在 E+ 的專屬 Notion + Discord 社群中見到大家 [E+ 的介紹頁面可以點這看到]。

講完 E+ 後，讓我們進到本週的雙週報主題吧～

[前端] 2024 前端框架趨勢預測

2024 年的最開始，讓我們一起來關心 2024 前端會有什麼趨勢發展吧。

除了過往比較大眾的 React、Vue 與 Angular，過去一年 Svelte、Solid、Qwik 等 UI 套件也都有了重大的進展；Web Components 也是，例如 Google 的 Lit 也在 2023 年的十月出了第三版。

不僅如此，在 2023 年前端與後端的界線似乎也逐漸變更模糊，例如 React 的 RSC 跨入伺服器端，或者 HTMX 讓後端工程師更容易跨入前端。在黃玄的《我的大前端世界观》演講中，他提到未來也許分野不再是前端與後端，而是系統與產品，而產品工程師都需要掌握整個技術棧，意即會是全端工程師。

前端未來會如何變化，也很難說準，畢竟在幾年前社群討論的焦點都在 PWA，但過去兩年的重點又變得很不同，現在幾乎多數前端框架都開始往伺服器端，例如 React 近兩年的 React Server Components。

Solid.js 的創作者 Ryan Carniato 先前寫了一篇《JavaScript Frameworks - Heading into 2024》談論 2024 年的 JavaScript 框架發展的討論。Ryan 在去年也發了類似的文章，也成功地預測到 2023 年 Signals、Hybrid Routing、Edge 會是 JavaScript 框架的發展主軸。

而在 2024 年，Ryan 仍然預測 Signals 會是討論重點，因為 Solid.js 而流行起來的 Signals，現在可以在 Vue 的 Vue Vapor，以及 Svelte 的 Svelte 5 都看見 Signals 的身影，可以預見在 2024 會有更多框架導入 Signals 的概念。

Signals 外，基礎設施導向的開發 (Infrastructure-Led Development) 是 Ryan 預測的第二個趨勢。去年許多提供部署 (deploying)、寄存 (hosting) 的平台，也開始提供更多服務。例如 Vercel 等多個平台都推出自己的 key-value 與 blobs 儲存方案，在 2024 年預計會有更多。

過去一年在全世界被廣泛討論的 AI，在 2023 年還沒有真的跟 JavaScript 框架有太完整的整合。不過 2024 年可預期會有一波導入。舉例來說，去年在社群引起討論的 million.js，推出整合 AI 的 million copilot，從框架的角度直接幫你檢測為什麼會有效能問題，以及可以如何改善。

對於 Signals、Infrastructure-Led Development 以及 AI 等趨勢，如果你還有不熟悉的，推薦可以趁 2024 年的最開始補齊相關知識！

[後端與系統設計] 節約架構 (The Frugal Architect) 的七大原則

上週讀到台大資工系的 Shih-Hao Hung 教授分享的貼文，談到「失傳的技藝」，該貼文是延續 ITHome 的主題報導，該主題報導摘要了 Amazon 技術長 Werner Vogels 的演講，並提到「在雲端運算資源垂手可得的今日，雖然傳統硬體的限制越來越少了，軟體開發人員可以更聚焦在功能創新與更快推出上市，但也因此忽略成本效益的重要性，有鑑於重視成本效益幾乎已成失傳的技藝，亞馬遜技術長提出節約架構設計法則，呼籲將成本意識納入軟體架構設計，進而達成永續目標。」

Shih-Hao Hung 教授談到「用白話來說，如今許多軟體開發者只想用現成的、易用的框架快速打造應用，忽視系統的成本與效率，而且長期如此，會造成嚴重的資源浪費，當然會影響盈利。」

並接著說「我常告訴學生，我們做系統效能優化的，只要願意好好學，不斷累積知識和經驗，會越做越得心應手。想入門的學生，要先學好計算機結構和作業系統，並且了解實際系統，藉此建立『設計』的基礎和成本的概念，才有能力改進原有的設計；其次是動手在實際系統或是模擬器上利用工具『量測』效能之後，洞悉效能的瓶頸，才能遂行第三階段的『最佳化』」

關於在做設計與開發時，把成本放在腦中，Amazon 技術長 Werner Vogels 其實有出了一個 The Frugal Architect，談七個簡單但有用的原則，因為篇幅緣故，這邊翻譯前三個讓大家參考 [原文在這]

原則ㄧ：將成本視為一種非功能性需求

非功能性需求定義用來評估系統運作的標準，而不是具體特定的功能。常見的例子包括無障礙性、可用性、可擴展性、安全性、可移植性、可維護性以及合規性。然而，其中經常被忽略的是：成本。

許多公司因忽略成本考量，從設計、開發到運營階段都失衡，或是缺乏適切的成本衡量機制，最終走向失敗。這道理再簡單不過： 如果成本高於營收，營運的永續就會有風險。

從最開始就持續將成本納入考量，可協助系统在功能、上線時效和效率之間取得平衡。開發階段能聚焦於精簡高效的程式碼，運營階段則能微調資源使用和支出，以最大化盈利。

原則二：能永續經營的系統，在成本與商業模式上需要相互契合

一個系統的持久性取決於其成本與商業模式的契合程度。在設計和建構系統時，我們必須考慮收益來源和利潤槓桿。找出關鍵的獲利指標，然後確保系統架構與其相輔相成，這至關重要。

例如，在電子商務中，關鍵指標可能是訂單數量。訂單增加時，基礎設施和運營成本也會上升。但這沒關係，因為如果系統的架構良好，您可以開始利用規模經濟的優勢。重要的是，基礎設施成本對業務要有可衡量的影響。

作為系統的建構者，我們需要考慮收益，並利用這些知識來指引我們的選擇。因為不計成本的增長只會帶來一系列的破壞。

原則三：架構是一系列的取捨

在架構的世界裡，每個決策是權衡與取捨。成本、韌性、效能等非功能性需求之間，往往互相角力。

俗話說「世上沒有永不失靈的事物，一切皆有可能在任何時候出狀況」，提高系統的容錯能力，意味著需要在韌性上做額外的投資，而這往往會影響系統的效能表現。

因此，技術與業務需求之間，找到最佳平衡點至關重要。這個平衡點需要考慮風險承受能力和預算等因素。請記住，節約是尋求最大化價值，而非一味地降低成本。做到這一點，就需要明確界定你願意為哪些方面付出多少代價。

The Frugal Architect 的完整七個原則，我們有完整翻譯放在 E+ 的《Amazon 技術長談 The Frugal Architect 的七個原則》一文當中，有訂閱 E+ 的讀者之後可以看到～

[職涯] DHH 談能力養成

Ruby on Rails 的創作者 DHH 在去年底分享了一篇《Commit to competence in this coming year》是特別適合作為 2024 年第一期雙週報摘要的文章。

要理解這篇文章，要先懂 competence 這個單字，這個字直接翻譯是指能力、本領，或者是在某個工作崗位上所需的必要技能。為什麼要談這個字，因為 DHH 認為在歲末年終，或者一年的最開始，很多人會說自己要有新年新希望，例如讀更多本書，或者做到 XYZ 等事情。

雖然有對新年的期望是好事，但 DHH 的觀點是，要達成這些新年新希望，往往需要有一些重大的改變，例如要養成一個新習慣，並不是一件太容易的事，雖然並非不可能，但許多人多半會半途而廢。

他的觀點是，多數人每週要花 40 小時，每年要花 2000 小時在工作上，如果這些時間當中，有 10% 是有意識地去提升自己，經年累月就會有很顯著的差異。他的論點核心要點在於「不用額外花時間」，而是在你已經會花的時間上，有意識地提升自己。

以寫程式來說，許多時候你已經知道如何寫某些程式碼，而因為你有熟悉的已知方式，在未來遇到相似的問題時，你可能會選擇用同樣的方式寫。只是當你一直這樣做，你就變得只會以單一思考方式解決問題。

從一個角度來看，遵循已知模式在長久累積後，能讓你在同樣的事情越做越快，這是經驗帶來的好處。但從另一個角度來看，這也是一種陷阱，因為這可能讓你忽略去探索新的可能性，例如不同解決問題的方法，久而久之雖然累積了經驗，但同時也讓自己停滯不前。

寫程式時有幾個層次，第一層是寫出來，第二層是寫出來且保證是寫對的，第三層是不僅是對的還寫得快，而 DHH 加上第四層，他認為要寫快之外還要寫的美。

想要能寫得美，就要培養出辨別美感的能力。DHH 指的美感不是裝飾或花俏，而是 4C (clarity, cohesion, consistency, and conciseness)，而要能夠有著 4C，他的具體做法是先把寫出來的第一個版本當草稿，然後再進一步去塑造。

DHH 認為，許多剛入行的初階工程師的通病是，不會去仔細、反覆，甚至痴迷地研究自己寫出來的程式能不能寫更好。不只是功能正確而已，還要一遍遍地修，直到程式碼足夠美。

雖然 DHH 很多言論頗具爭議性，但是這篇《Commit to competence in this coming year》 寫的很實在。有意識地精雕細琢自己寫過的東西，將能幫助自己不斷在程式路上有所提升。

如果要多加一點，我們認為去研讀其他人寫的程式碼，然後回頭看可以如何改寫自己的，也會很有幫助。畢竟很多時候自己的觀點是有局限性的，透過閱讀別人寫的，可以獲得一些啟發，以及不同切入的角度。

總的來說，如 DHH 所言，有意識去琢磨與提升，可以不用是很花時間的，每天 10% 的日積月累，回頭看就會有極大的進步！

[本期推薦連結]

• 這週 Vue 官方推出了這個頁面，說明 Vue 不只可以用來打造 SPA [連結]

• 如果你對 React 的 Suspense 還不熟，這個《The Complete Guide To React Suspense》寫得蠻清楚的，推薦一讀 [連結]

• 假如你過去有因為 npm 套件管理工具用了不合適的，而導致沒辦法順利安裝，最近看到社群中有人分享 Anthony Fu 做的 ni 有效幫你用對的套件管理工具 [連結]

• 最近 Rust 的 Rails 框架 Loco 在社群有不少討論，如同 Rails 讓寫 Ruby 省了很多事，Loco 也讓開發後端省很多事 [連結]

• 不少公司在 AI 浪潮後，會結合爬蟲與 AI，這篇《Building a Universal AI Scraper》作者分享如何打造一個 AI 爬蟲器，這篇也蠻推薦給對寫技術設計文件有興趣的人，原作者分析不同方法，也展開最後的流程，都是技術設計文件需要的內容，且文筆精鍊，很值得一讀 [連結]

• 前兩週看人分享 Dmitry Soshnikov 所教授的直譯器課程《Essentials of Interpretation》的筆記 [連結]，覺得寫得很不錯，推薦對直譯器 (interpreter) 主題感興趣的人，可以讀這系列筆記 [連結]

• 很多公司都有加班文化，但是加班不僅對員工有害，對管理者也是，最近讀到哈佛商業評論這篇，談說下班時間繼續想工作的事，反而對工作表現有害。工作與生活平衡不只是幫助生活，也是幫助工作呀 [連結]