[前端] 身為前端工程師,你該追蹤 Rich Harris
Svelte 一直是最受開發者喜愛的前端框架,雖然 Svelte 5 還沒正式推出,但這週 Svelte 團隊發佈了 Svelte 5 中會有的一個新概念 Runes,引來前端社群一陣討論。這一期我們不會特別談 Runes (但非常推薦你也去了解一下,連結在此),而是要來聊聊 Svelte 的創作者 Rich Harris,以及為什麼你該追蹤他、看他寫的內容,以及聽他給過的講座。
Rich Harris 是一名具有獨特觀點的工程師。所謂的獨特觀點是指與主流不同,但又很有啟發性的觀點。舉例來說,在 React 帶起的虛擬 DOM 風潮時, Rich Harris 發表了《Virtual DOM is pure overhead》一文,點出雖然虛擬 DOM 只會在比較前一個版本後,只更新有改變的部分,讓更新速度快,但是「比較 (diff) 哪些部分需要更新」這件事本身就需要時間,而且這是個多餘的計算 (overhead)。
會說是多餘的計算,是因為 Svelte 透過編譯器,在建構環境時就知道各種改變之間的關係,所以讓你可以用宣告式 (declarative) 的方式寫前端的同時,可以完全不用額外的虛擬 DOM,也就省下額外比較前後版本的計算。
而在 Svelte 3 發表時,Rich Harris 也寫了篇《Rethinking reactivity》來重新思考響應式 (reactivity) 的概念。Svelte 從編譯器角度出發,這對社群有相當大的影響。舉例來說,React 在 2022 年提出了 React Forget,也是試圖從編譯器的角度去減少響應式所需的程式碼 (現在 React 需要用 useMemo
與 useCallback
來減少避免多餘渲染,但這讓程式碼變很雜亂)。
在今年他給的講座《Rich Harris on frameworks, the web, and the edge》中,更是提出了好幾個辛辣的觀點,每一個都很值得你聽完後思考。包含挑戰了前端社群追求「零 JavaScript」的熱潮,以及提出使用者體驗比起技術細節更加重要。
以我們自己的經驗,在剛開始接觸前端開發時,也是會選邊站,例如覺得自己是 React 派。只是隨著讀越多、實作經驗越多,開始意識到不同工具與不同觀點,沒有絕對的好壞,只有適用的情景與取捨。唯有突破這個思維,才可以真的稱自己為前端工程師,而不是侷限於 React 工程師。
除了我們熟知的三大框架與今天介紹的 Rich Harris,我們也相當推薦追蹤其他不同前端框架的創作者, Qwik 的 Miško Hevery、Solid 的 Ryan Carniato,以及 Astro 的 Fred K Schott。多接觸不同觀點,多去思考為什麼他們這樣說? 自己哪邊同意哪邊不同意,會讓自己成為更好的前端工程師。
[後端與系統設計] 系統設計五大心法 (1) — 水平擴張 (Horizontal Scaling)
在過去三期全端雙週報,我們透過蛋糕店的例子,帶大家理解系統設計的概要。然而要做好系統設計,或是在系統設計面試中有突出的表現,必須深入細節。雖然說面對不同的系統,會需要針對需求與特性,去做特別的調整,不過有許多心法是在各類系統都適用的。在接下來的五期,我們每一期會聊一個心法。
第一個要談的心法是水平擴張。要擴張一個系統通常有兩種方式,一種是垂直擴張 (Vertical Scaling),也就是去提升單體機器的能力,例如增加 CPU 的核心數,或是增加記憶體,或是把硬碟升級成 SSD。 但是單一硬體總是有其極限所在,因此一直升級到最後仍會遇到瓶頸。這也是為什麼多數時候,在系統設計時,會選擇水平擴張 (Horizontal Scaling)。
水平擴張做的事情,就是透過複製或拆分伺服器與資料庫,來分散系統負載的壓力。而要做到這件事,會透過均衡負載器 (load balancer) 來實現。當請求進到系統時,均衡負載器會將請求轉去給不同的伺服器處理。這也是幾乎在所有系統設計面試中,平衡負載器基本上一定會在你的系統設計圖當中。
常見的均衡負載方式包含隨機 (random) 分配給伺服器、輪詢 (round robin) 分配、最少連接 (least connection),以及一致性雜湊 (consistent hashing) 等各類方法。在實務執行上,通常也會加上權重 (weight),每種方式都有其要考量的點,推薦大家可以多深入去理解不同方法的取捨。
當談到水平擴張,就不能不提「狀態」這件事。有狀態會導致服務被受限,因為請求打過來,只能去找具有狀態的那個伺服器;這時如果具有狀態的伺服器的單點掛了,要處理就比較麻煩。這也是為什麼在水平擴張的系統設計中,會讓各個微服務無狀態。當你在設計系統,或是在面試時被面試官問到要不要有狀態時,你的雷達要記得響起來,然後說「不」。
當選擇無狀態的設計,某一台伺服器掛了,均衡負載器可以把請求導向其他台伺服器。在實務上,我們經常會使用心跳檢測 (heartbeats) 來判斷伺服器是否還正常運作。簡單來說,就是會定期發心跳請求給伺服器,如果伺服器在一定時間沒有回應,則會被判斷為出問題,這時就會把請求轉去備用的伺服器。這做法也適用在均衡負載起本身,來確保如果均衡負載器掛了,隨時有備用的均衡負載器可以接手。
以上簡述了系統設計五大心法中的水平擴展,水平擴展確保了系統能承載更高的流量。同一個好的系統不能只停在這。在下一期我們將談幫助系統加速的心法 — 快取 (cache)。
[軟體業職涯] 找人幫忙內推要注意的事
在經歷今年上半年的裁員潮,最近世界各地的軟體業開始慢慢回暖。有些在上半年裁員的公司,現在已經逐漸重啟招募。假如你是有打算換工作,特別是想要進軟體大廠或外商公司,內部推薦 (referral) 會是比自己在申請網站上投遞履歷,還要更有效的方式。
如果你想要找人幫你內推,在台灣的軟體工程師社群中,有歹晚郎內推互助網絡與 Nex Work 等由海外軟體業前輩發起的內推網絡 (不確定現在還有沒有被維護)。此外,也可以在 LinkedIn 或是 Blind 上,搜尋 #referral 的標籤,或是找有在該公司任職的人,然後禮貌地發個私訊請對方幫忙內推。
當然,很多時候可能不會立即得到回應,又或者可能對方太忙沒回應,也不要感到氣餒,可以多詢問同一間公司中不同的人幫忙內推。在找人內推,如果能依循某些注意事項,將比較容易會讓人想幫你忙。以下我們分享幾個推薦大家要遵循的原則:
履歷好好寫:在各大海外公司工作的人,也知道自己公司的標準,所以不會來者不拒、盲目內推。你想提高別人內推你的意願,務必要好好寫履歷。好好寫代表著格式上要正確,以及內容描述上要讓人覺得你有達到對方公司想要找的人才水準。假如不知道怎麼寫好履歷,可以參考我們先前寫過的履歷撰寫文 [連結]。
附上想被內推的職位:在多數大公司,光是一個大組可能就幾百人,比一間新創公司還大,因此除非是專職招募的招募員,或者是工程經理,不然多數人其實不知道其他組現在有什麼職位開缺。所以不要找人內推時,還說什麼「你有沒有推薦我申請哪些職位」,這只會讓人覺得你沒做功課。大家平常工作已經夠忙了,沒空幫你去看你適合申請的職位,所以務必自己附上。通常大公司的職缺都會有 Job ID,可以附上你想申請的。
附上你為何適合這個職位:內推的人也不會想自己在公司內的名聲臭掉,所以多半會先判斷你是不是真的適合被內推。如果你想提高別人內推你的意願,你就要做到讓別人會認為你適合被內推。要做到這個,務必附上你為何適合你想被內推的職位。理想上也要附上為何你適合該公司 (建議多做一些功課來研究該公司,進而能闡述你為何跟該公司文化契合)。
表達感謝:假如一個原本跟你不相似的人,願意內推你。務必要表達感謝。因為大家平時工作很忙,可能還有家庭的事務要兼顧,額外抽時間幫你,這件事本身就很佛心,千萬不要把別人的善意視為理所當然。即使內推沒有讓你拿到面試機會,也要記得感謝對方。畢竟很多公司冷凍期半年,你之後還可以再嘗試,與對方維持良好關係,這次沒上之後要請對方幫忙也會讓對方更有意願。
以上的原則不限於工程師,推薦給所有想要找外商或海外軟體公司工作的人。如果有關於內推相關的問題,也歡迎留言讓我們知道!
本期推薦
預告出來兩個月後,由 OfferZen Origins 推出的 TypeScript 紀錄片正式上線了!這部紀錄片訪談了 TypeScript 的創作者,以及在 TypeScript 社群中有名的開發者們。必須說現在程式界的紀錄片都拍得很精彩,非常推薦大家一看 [連結]。
Vercel 推出透過自然語言生成 UI 元件的 AI 工具 v0。你只需要輸入提示詞 (prompt),v0 就會根據你的提示詞,生成出相對應的 UI 元件完整程式碼。換句話說,透過 v0,用嘴巴寫 UI 元件這件事不再只是說說,而是真的被實現了。更重要的是 v0 的「複製貼上」的設計,是可規模化前端的重要設計原則。如果你不知道為什麼這重要,推薦一讀這篇文。
前兩期的雙週報要談到,10 月初將會有 ViteConf,目前講者名單陸續出爐,陣容非常豪華,還沒報名的人別錯過了 [連結]。另外,還沒用過 Vite 的人,其實遷移到 Vite 比你想的簡單,這篇文章很帶你一步步從 Webpack 遷移到 Vite。
除了 10 月初的 ViteConf,10 月底也有 Next Conf [連結]。上面提到的 v0 外,相當期待在最新的 Next Conf,Vercel 還會端出什麼更讓人驚豔的成果。
builder.io 預告下個月將發表一個徹底改變 Figma 轉程式碼的 AI 工具,不論你對 UI 設計有興趣,或對前端開發有興趣,下個月的發表,都值得你期待一下。這次發表會的報名網頁,就直接讓你可以在頁面上方拉設計,然後下方直接展示即時改動元件程式碼,推薦大家報名的同時可以去玩玩 [連結]。
上期雙週報介紹了 Bun,很多人問各個部署平台有支援嗎?Vercel 與 Netlify 等部署平台馬上跟進。 不過 Bun 作為多合一的 JavaScript 工具也並非沒有風險,Cory House 這個貼文很值得大家讀與思考 [連結]。
多數的軟體大廠,除了有產品經理與工程師,也都會標配資料分析師。因為在打造產品時,只用個人經驗或單一視角,是會有局限性的。而統計與資料,彌補了個人經驗的侷限。《The limits of our personal experience and the value of statistics》一文很好地闡述了這個觀點,推薦大家一讀。
ExplainThis 致力讓全端雙週報保持永久免費閱讀。為了能更永續經營這份電子報,我們開放電子報開頭的版面贊助。目前電子報有超過 1400+ 位讀者,平均開信率 > 60%,受眾主要是對軟體全端開發感興趣的讀者。如果你有認識合適的廠商,還請推薦給我們 🤝
另外,雖然電子報為免費訂閱,但我們將留言發問保留給付費訂閱的讀者,在電子報的留言我們都一定會回覆。如果你有任何問題或想交流的,都歡迎在留言區發問 🙂