ExplainThis 全端開發雙週報 #14
Next.js 14 有什麼新功能與變動、系統設計五大心法 (4) — 避免單點故障、L3 升遷到 L4 具體要做哪些事
Hi，歡迎閱讀最新一期的 ExplainThis 全端雙週報，我是雙週報主筆 Li。兩週前 ExplainThis 開始經營 IG 帳號，比起電子報，IG 會是更圖文導向的方式分享內容。歡迎大家追蹤 [IG 連結]。
另外我自己也開了一個 Facebook 粉專 [連結]，以及 IG 帳號 [連結]，會更聚焦在分享科技與職涯相關的內容，有興趣的朋友也可以追蹤。
最後，因為陸續有收到讀者來訊，詢問工程師職涯相關問題，ExplainThis 最近正式規劃完諮詢與模擬面試等服務，有需求的朋友可以參考 [連結]
講完了 ExplainThis 的近期更新，接著讓我們進到本期的正式內容吧 🙂
[前端] Next.js 14 有什麼新功能與變動?
有別於 React 現在幾乎是三年一個大版更新，Next.js 持續每年一大版更新的節奏。在今年的 Next Conf，也不意外地宣佈了 Next.js 14。在這期我們來聊聊 Next.js 14 有什麼改變。
首先，這次最讓人拍手叫好的是，Next.js 14 沒有新的 API。沒錯，沒有新的 API，從工程的角度來說，在不改變 API 的前提下擴充更完整的功能，是相當不容易的。比起 Next.js 從 12 升到 13 版時的各種大改，沒有新的 API 意味著讓人升版到 14 的阻礙變小。
具體來說，這次 Next.js 14 的發表有幾個重點，第一個是 Turbopack 愈趨完善，第二是 Server Actions 進到穩定版本。另外 Next.js 團隊也推出了 [Partial Prerendering] 的預覽。
先來講 Server Actions，這次 Next Conf 後，網路上流傳各種 Sam Selikoff 的迷因圖，例如這張 `'use binary'`
這張梗圖是源自於 Server Actions。所謂的 Server Actions 是讓你不用額外在 Next.js 的 `/api` 底下創建 API 就能直接在 Next.js 的 App Router 中，創建一個帶有 `'use server'` 的函式，然後直接在 Server Component 中呼叫。因為這寫法跟 PHP 的設計相似，在社群上許多人批評 Next.js 的設計。
關於這點，我的觀點是，與 PHP 的設計相似沒有什麼不好的。React 的最開始從客戶端的角度切入，現在往伺服器端走，讓前端開發者可以更輕易地往全端發展，讓前端開發者可以掌握完整的用戶體驗，這件事本身的意義就足夠大了。
除了 Server Actions 外，這次 Next.js 14 的一個亮點是 Partial Prerendering 的預覽。在過去 CSR、SSR、SSG、ISR 各種模式下，開發者總需要在效能與個人化中找到平衡。
Partial Prerendering 則能讓你兩者兼顧。在頁面中，通用的部分，會先被渲染，而需要個人化的部分，則透過 React 的 `Suspense`，可以先展示出 `fallback` 的內容，然後接著向伺服器端拿到資料後，再透過串流的方式進一步渲染。在 Partial Prerendering 的設計下，不只首屏渲染快，動態內容的部分渲染也快。
看完 Next.js 14 有興趣升級的人，可以參考這個文件 [連結]
最後，這次 Next.js 14 發表的同時， Vercel 宣布了全新的 Next.js 官方教學。不得不說現在的官方教材越來越卷，先前 React 改版後的官方教材，基本上讓人完全不用額外買什麼課程，就算買了也不會比官方的好，不如看官方的，還免費。現在 Next.js 也跟上這種做法
這次 Next.js 的教學文件，不只整個改版，還新增了 Next.js 全端開發的教學，跟著一步步做，就能完整從開發到上線。只能說未來要學好全端開發，不需用在買課程了 [教學連結在此]
[後端與系統設計] 系統設計五大心法 (4) — 避免單點故障
前三期的雙週報中，我們談了均衡負載 (load balancing)、快取 (cache)，以及非同步 (asynchronous) 這三個系統設計心法，在這一期我們將進一步來談第四個心法 — 反單點故障。
所謂的單點故障 (Single Point of Failure，簡稱 SPOF) 指的是系統中的某個單一節點失效時，導致整個系統無法運作進而崩潰。這對於系統來說，最直接的影響就是可用性 (availability) 會降低，而對任何系統來說，這都是不樂見的事情。也因此，在系統設計時，這個概念特別重要。
在往下講之前，先來了解一下可用性，以及一些關於可用性大家需要知道的概念。假如要用白話來理解，可用性是指系統可供使用的時間；通常我們會用 `系統可供使用的時間 / 總時間` 這個比例來衡量。舉例來說，業界常用的 99.99% 可用性，即是指一年只有 52 分鐘系統是不可用的 (365 天 x 24 小時 x 60 分鐘 x 0.0001 會是約 52 分鐘)。
在業界，大家常會看到 SLA (Service Level Agreement) 即是針對可用性的協議。而常聽人說的「幾個 9」則是在描述 SLA 上的比例。以上面的 99.99% 來說，會被說四個 9；如果是 99.999% 則會被說五個 9，往下以此類推。
在業界通常違反 SLA，都是會有相對應的賠償，舉例來說，假如你用某個 AWS 的服務，SLA 寫四個 9，結果該年 AWS 掛掉超過 52 分鐘，AWS 的合約上會有他們相對應要做的賠償。身為設計系統的人，你肯定不想系統掛掉超過 SLA 協議的規範，不然系統掛掉造成客戶的損失，也是需要自己來承擔。
要做到高可用，避免單點故障，就會是非常重要的。要避免單點故障，有幾個重要的概念，首先要避免系統中的模塊有過高的相互依賴，減少依賴就能避免「一個地方壞掉，造成整個系統崩掉」的狀況。
然而，假如有某些關鍵依賴，就是沒辦法不依賴，這時可以則務必要避免某個模組有熱點，意即被大量地請求，先前提的均衡負載就能來做到這件事。除此之外，有備案也是非常重要的。常聽人說的冗余 (redundancy) 即使如此，如果某個模塊掛掉了，備案可以馬上接替。
以上，是這一期針對可用性、SLA，以及避免單點故障的介紹，這些概念都是設計一個系統時一定要放在腦中的。這系列已經介紹了四個心法，在下一期我們將向大家介紹最後一個心法 — 監控 (monitoring)。
[科技業職涯] L3 升遷到 L4 具體要做哪些事?
上一期雙週報摘要了 Meta 主任工程師 Ryan Peterman 先前寫的 L3 與 L4 工程師的差別，這一期我們將延續這個主題，摘要他分享的，假如想從 L3 晉升到 L4，可以具體做些什麼來達成。
如上一期提到，在科技大廠的升遷中，有個重要的概念是「唯有當你持續展現出自己有能力做下一個職級在做的事，才會被認定夠格升遷到下一職級」，而這邊的持續，指的是至少要六個月 (半年)。為什麼呢?
因為從公司的角度來看，這樣做可以降低你升上去之後，可能會達不到預期表現的風險。如果你能穩定半年都達到下一級的表現，公司就相對不用擔心你升上去後，沒辦法勝任新職級的任務。
Ryan 提到，要加速升到 L4，有兩個關鍵，第一個是跟自己的直屬主管溝通「你有想升遷的渴望」，讓你的主管可以為你安排 L4 級別的任務和資源。第二個是你需要優化你的開發速度，用更的速度完成開發，這項能力會讓你更能勝任 L4 的任務。
就一般而言，只有超級強的人可能在一個半年完成 L4 升遷，因為要做到這樣，代表你一進入公司就立刻就達到 L4 的標準，並在接下來半年維持該水平。若能在一年完成升遷也很不容易，如果是有野心的人，Ryan 推薦可以設定這目標，前半年適應新的工作環境，後半年維持住 L4 的期望，就有機會順利升職。
Ryan 也分享自己的經驗，他花了一年達到 L3 升遷 L4，具體做法是前半年除了完成被交辦的任務，也開始主動做一些程式碼重構的工作。而這些額外的工作，證明他能做到 L4 的程度。
他也提到，如果能重來，他會更聚焦跟主管討論如何達到 L4，而不是把 1:1 浪費在更新工作進度上。此外，他不會什麼任務都接下來做，而是會先確定項目能有足夠程度的影響力才做。
除此之外，他提到跟主管校準預期很重要，在他進到 Meta 前半年，同事就跟他說他已經做到 L4 的程度，只是他沒去跟主管校準，但最後沒能有效升遷，他說如果有更主動去跟主管校準，這狀況將能夠被避免。
以上摘要，L3 到 L4 升職的具體作法。在下一期，我們將延續這主題，摘要 L4 與 L5 的差異，以及如何可以從 L4 邁向 L5。
本期推薦
美西時間下週一 (11/6) 就是社群上許多人等不及的 OpenAI 首屆 DevDay。假如沒辦法到現場也不用擔心，可以在 OpenAI 的頻道上觀看直播 [連結]
主打 AI Pair Programmer 的 Phind 宣稱自己的最新模型，在程式生成的比分好過 GPT-4 [連結]。但我自己試過後，覺得 GPT-4 的效果仍比較好。不過 Phind 的 Pair Programmer 功能設計得相當不錯，你丟需求給 Phind 時，他會真的像跟你一起寫程式的同事，反問一些要釐清的問題，這種互動對於工程師的進步來說，蠻有幫助的。雖然我自己目前仍偏好基於 GPT-4 的 Cursor，但還是推薦大家可以玩玩 Phind [連結]
看到 Vue 創作者尤雨溪的這篇推文 [連結]，非常有感。不只是簡中，繁中的社群也存在許多不友善與包容的狀況。我自己好一陣子不看 PTT 軟工版，就是覺得裡面好戰的言論，多數時候沒有建設性，讀了也覺得很消耗。營造更友善的技術社群，你我都能盡一分力！
前兩週在 React Advanced 大會上，React 核心團隊分享了 React Forget 的最新動態 [連結]。React Forget 算是我個人很期待的新功能，假如真的推出了，React 程式碼將會簡潔非常多
Serverless Postgres 資料庫 Nile 正式進到 private beta 了。目前社群中比較熱門的 Postgres 選項是 Supabase，很高興看到社群中有更多選擇。畢竟有競爭，避免一家獨大，是軟體社群能持續往前推進的動力。我個人特別喜歡 Nile 強調開發者體驗這點，推薦給有興趣的人加入等候名單去玩玩 [連結]
ByteDance 的 Rspack 推出了靜態網頁生成器 (static site generator) Rspress [連結]。由於是用 Rust 寫的，所以在冷啟動、熱更新的效能上，比起目前社群中常見的 Docusaurus 快非常多。上期雙週報提到 Vite 團隊找來 Rspack 核心團隊的前成員來協助優化效能；這週看到 Discord 從 Webpack 遷移到 Rspack，建構時間加速 70% [連結] 可以看到前端工具鏈現在越來越多團隊與專案選擇 Rust，來作為優化效能的手段。
筆記軟體 Obsidian 的執行長寫了一篇《Quality software deserves your hard‑earned cash》讓人感觸良多。雖然許多軟體工程師的目標是 FAANG 等大廠，但因為有投資人與市場的壓力，匠人精神 (craftsmanship) 很難在大廠被實踐。高品質的軟體產品絕對值得被付費支持。我個人目前心目中理想的高品質軟體，除了 Obsidian 還有 Linear。看到這種高品質軟體產品，有時候真的會自覺慚愧，同時又身心嚮往。
感謝閱讀至此的你，如果你喜歡 ExplainThis 雙週報，還請多推薦給身旁的朋友 🙂
另外，最近 ExplainThis 團隊開始籌劃一些進階學習資源。如果你有軟體工程求職與進修相關需求，歡迎填寫問卷讓我們更了解你的需求，以規劃更好的學習資源 [問卷在此]