ExplainThis 全端開發雙週報 #15
你很常聽到 monorepo 但為什麼要用 monorepo、系統設計五大心法 (5) — 監控、科技大廠的資深工程師與中階工程師的差別
Hi 歡迎閱讀最新一期的 ExplainThis 全端雙週報，
上週在雙週報中有分享 ExplainThis 最近正式規劃完諮詢與模擬面試等服務，有需求的朋友可以參考 [連結]。目前 11 月的諮詢都排滿了，由於 12 月底 ExplainThis 成員都有休假安排，目前還有 5 個時段的名額。如果在年底前有求職、職涯相關的問題，或是想練習模擬面試，都歡迎填寫申請。
另外，ExplainThis 的 IG 即將達到 1000 追蹤，還沒追蹤的讀者推薦追蹤，IG 上會有最新的產業資訊分享 [IG 連結]。另外我自己也開了一個 Facebook 粉專 [連結]，以及 IG 帳號 [連結]，會更聚焦在分享科技與職涯相關的內容，有興趣的朋友也可以追蹤。
講完了 ExplainThis 的近期更新，接著讓我們進到本期的正式內容吧 🙂
[前端] 你很常聽到 monorepo，但為什麼要用 monorepo?
身為前端工程師，或許你很常聽到別人說用 monorepo 的好處很多。以前端來說，Lerna、Nx，以及 Turborepo，都是社群許多人會用的選擇。多數大公司的前端基礎建設團隊 (frontend infra team) 都會有專職在負責 monorepo。但是什麼是 monorepo? 為什麼要用 monorepo? 好處是什麼? 在這一期我們將與大家聊這個主題。
所謂的 monorepo，是由 mono 跟 repo 組成的，mono 在英文的字首有單一的意思，而 repo 就是 repository 也就是程式碼庫，所以組合起來 monorepo，就是指用單一程式碼庫，來存放不同項目的程式碼管理模式。相對來說，假如把不同項目，放在不同的程式碼庫，會被稱為 polyrepo。
在了解完 monorepo 的基本定義，下個問題要問的是，它解決了 polyrepo 的什麼問題? Turborepo 官方文件的說明範例，非常淺顯易懂，這邊摘要給大家
在 polyrepo 的模式下
你有三個不同的程式碼庫：一個是應用程式 (app)，一個是文件 (docs)，還有一個是共用的工具 (shared-utils)。因為想要共用 shared-utils，我們需要把它發布到 npm 上，讓 app 和 docs 安裝並都依賴 shared-utils。假設 shared-utils 有個 bug，這個 bug 對 app 和 docs 都造成問題。當你修完這個 bug 之後，需要這樣做：
在 shared-utils 提交一個修復 bug 的更改
在 shared-utils 內執行發布任務，將新版本發布到 npm
在 app 更新 shared-utils 的版本
在 docs 中也做同樣的版本更新
然後 app 和 docs 才能準備部署
如果有越來越多的應用程式依賴 shared-utils，這個流程就會變得更長更繁瑣。
假如用 monorepo
shared-utils 與 app 和 docs 在同一個程式碼庫中。這使得過程變得非常簡單：
在 shared-utils 中提交一個修復 bug 的更新
app 和 docs 就準備好可以部署
用 monorepo 代表不需要進行版本控制，因為 app 和 docs 不依賴 npm 中的 shared-utils 版本，而是依賴 monorepo 中的版本。
從上面得例子，可以看到 monorepo 顯而易見的好處是，共享程式碼變很簡單，同時能做到原子化更改，在更改共用的程式碼時，同時可以在同一個更新中，修改依賴該程式碼的應用程式，這樣做可以避免在多個程式碼庫之間協調更新的麻煩。
此外，因為都在同一個程式碼庫、依賴單一的版本，可以減少應用程式之間的不一致性。即使是不經常更新的應用程式，也能跟最新版本。這對開發人員的負擔，會明顯小很多。
讀到這邊你可能會問，那為什麼我們不把所有程式碼都放在一個程式碼庫，只有一個超大的項目，不用分項目，這樣也可以做到共享，為什麼還要 monorepo 這種種架構呢?
單純把程式碼放在一起(code collocation) 確實可以輕易共享，且做到依賴單一版本並，但也有顯而易見的問題，包含執行不必要的測試，在單純的程式碼並置中，即使更改和某些項目無關，整個程式碼庫的所有測試都會被執行。這就好像為了一個小變動，讓所有不相關的專案也受到影響。
此外，這也會讓程式碼相對沒邊界，如果一個團隊的開發者修改了另一個團隊的程式碼，可能會引入錯誤或不一致。因此，我們需要一個架構，讓我們享有程式碼並置 (code collocation) 好處，同時避免其壞處，monorepo 即是能做到這樣的解決方案。
以上是針對 monorepo 的介紹，以及聊了為什麼要 monerepo。基本上現在多數的科技大廠都是走 monorepo 的模式，假如你還沒用過，推薦可以試試上面有提到的 Lerna、Nx 或 Monorepo。
[後端與系統設計] 系統設計五大心法 (5) — 監控
在前面四期雙週報，我們陸續談了系統設計的常見心法，今天這個系列將來到尾聲，我們將在這期聊一聊監控 (monitoring)。監控在真實世界的系統中，是非常重要的環節，其核心在於能預測並協助系統在問題發生前主動發出警告，讓問題發生時相關人員能立即處理。
監控要設計的好，需要確保故障的檢測、警告的發出，以及問題定位的容易程度都能被照顧到。設計的好的監控，將讓維運的人，能快速上手，並能低門檻地接手 oncall 的任務。
針對上面提的點，我們一個個來談，首先是故障的檢測，要能夠有效檢測故障，需要定義好明確的指標，該要追蹤的都有追蹤到。在這個環節如果有缺失，很可能會導致在問題發生時，系統沒有辦法立即發出警告，導致出問題了沒人知道。在準備系統設計面試時，推薦針對每個題目，都練習發想在該系統下，有什麼是一定要監控的指標。
接著是警告的發出，在設計監控時，要確保過多的警告噪音 (無效的警告)。因為噪音不僅會造成團隊的疲勞，還可能導致真正的問題被忽視。就像狼來了的故事，如果野狼一直沒出現，大家就會開始覺得警告是無效的，這樣等狼真的出現時還以為是沒事，那將錯過問題的黃金處理時間。
因此，在系統設計中，適當的警告閾值設計和過濾機制，都是是至關重要的，它們能協助減少錯誤警告發出。在實務上，通常會針對每次發出的無效警告，都進行審查，確保未來同樣的無效警告會被過濾掉。
最後是問題定位的容易程度。當監控系統發出警告說有系統錯誤，這時開發與維運人員，需要第一時間定位問題，並處理問題。有效定位出問題，是能夠協助加速處理問題的關鍵。要有效定位，就需要確保分級有做好，在實務上，會需要在應用層 (例如 QPS、可用性的監控)、系統層 (例如 CPU、RAM 的監控)，以及基礎設施層 (例如機房與網絡的監控)，都有監控。
舉例來說，如果在基礎設施層沒有監控，很可能應用層的監控發出警告，但因為問題不是出在應用層，所以應用層排查不出所以然，這會浪費很多不必要的時間。
總的來說，好的監控設計，應該要能有效檢測出錯誤，同時讓開發者與維運人員，能輕易定位出問題所在，協助開發者迅速發現線上程式碼的問題。此外，要避免發出不必要的噪音，從而提高報警系統的準確性。
[職涯] 科技大廠的資深工程師與中階工程師的差別?
前兩期的雙週報，我們摘要了 Meta 主任工程師 Ryan Peterman 先前寫的 L3 與 L4 工程師升遷相關內容。一般來說，L4 是指中階工程師，而如果想要在科技大廠成為資深，需要往 L5 邁進。這期我們將摘要究竟什麼是 L5 資深工程師的定義。
L5 資深工程師與 L4 中階工程師的主要差異，不僅僅是技術能力上的差異，更重要的是行為和影響力層面的差異。具體來說，資深工程師需要在團隊中發揮領導和影響力，讓我們透過以下範例解說：
優化程式碼庫：如果只是重構和清理程式碼，是屬於 L4 等級的。而 L5 等級則是需要，更進一步帶領團隊來共同優化程式碼。
維運與處理線上問題：如果只是參與團隊的 oncall，並在有問題時處理，這是屬於 L4 等級的。而 L5 等級則需要去優化 oncall 的工作流程，讓團隊中的人能更有效處理 oncall 時遇到的問題。
專案方向：L4 能夠負責一個中到大型功能的專案，而 L5 則需要進一步推動團隊規劃，並建立多個中到大型功能的專案路徑圖。
以上這些差異主要在於行為上的轉變。L5 的做的事不必然比 L4 更難，只是在心態需要轉變，進一步從「個人」轉變成「團隊」的視角來看所做的事。從上面的例子可以看到，對於 L5 資深工程師來說，軟技能 (soft skills) 變得更加重要，因為 L5 做的事情不再局限於自己，而是去領導和影響其他人。
只要能做一名好的團隊成員，就會被當成一個好的 L4 中階工程師。L5 工程師則不能侷限在自己，從專案範圍 (project scope) 的角度來說，L5 工程師處理的範圍大於 L4 工程師，具體來說，L5 通常專案是以月來衡量，且有 3 人以上參與的範疇；而 L4 工程師通常是幾週內能完成的範疇，且通常是自己一人就能完成的範疇。
除此之外，L5 工程師要去責指導他人和建立團隊文化，例如撰寫文件、知識分享、協助面試與招募、籌備團隊的活動等。
以上摘要了許多人關心的資深工程師 (L5 等級) 要做到的事項，下一期會繼續這個主題，來摘要怎麼樣可以讓你加速達到資深工程師的等級。
[本期推薦]
在 Vite 4 推出將近一年後，Vite 5 正式推出了 [連結]。現在前端社群的多個框架，包含 Astro, Nuxt, SvelteKit, Solid Start, Qwik City 都是採用 Vite。假如你還不知道 Vite 是什麼，可以參考先前我們寫過的 Vite 基本介紹 [連結]
最近開源專案 tldraw 在社群引起廣大的迴響，tldraw 原本是以線上白板出發的開源專案，最近爆紅是因為搭上了生成式 AI [連結]
HoneyPot 推出 Ruby on Rails 紀錄片，其主角 DHH 一直是個鮮明且具爭議性的人，但你不能否認他的觀點對於社群的貢獻。非常推薦大家一看 [連結]。另外，這邊友情推薦 RubyConf Taiwan 2023 將在 12/15 與 12/16 舉辦，推薦有興趣的人可以參加 [連結]
Builder.io 的 Steve 的這個開發 AI 應用的影片，非常有洞見。假如要深入為某個領域打造 AI 應用，LLM 不必然是最佳解 [連結]
最近看到這個開源的新創公司 CTO 手冊，裡面分享了作為新創公司 CTO 所學到的，很多點寫的很深刻。對工程管理有興趣的人，推薦一讀 [連結]
現在社群主流的 TailwindCSS 常會被抨擊說
class寫到太長太難讀。雖然以我們自己的經驗來說，沒有特別覺得這是問題，但這一篇講如何有效管理 TailwindCSS 的文章還是頗值得一讀 [連結]先前讀到這篇在聊 YouTube 廣告阻擋的文章，裡面稍微提及了廣告阻擋如何運作，雖然技術內容不多，但想當有趣 [連結]