Skip to main content

Command Palette

Search for a command to run...

序 - 系列文起源

Updated
1 min read

想精通一件事情,就逼自己教會別人。

這個系列會關注在開發過程中的概念,實作方式,因此並不會涉及 環境架設

最近閱讀了《The Diary of a CEO: The 33 Laws of Business and Life》,書中有一個概念讓我深受啟發:「想精通一件事情,就逼自己教會別人。」

這個系列文章的誕生,源於我最近帶領的幾位新進工程師。我想,如果這些經驗傳承只停留在公司內部的教育訓練,能受益的僅有寥寥數人;但若能將這些內容整理成公開文章,或許能幫助更多正處於迷惘期的開發者。

因此,這 30 堂課將聚焦於開發過程中的核心概念與實作思維,我們不會花篇幅去講繁瑣的環境架設,而是深入探討一個軟體產品誕生背後的硬實力:從設計模式、資料庫設計,到系統架構、網路架構以及資訊安全

拒絕成為 AI 時代的「Vibe Coder」

雖然 AI 工具的飛速成長大幅降低了「撰寫」程式碼的門檻,但也帶來了隱憂。如果我們沒有提升自己的軟體底層能力,只是無腦地依賴 Prompt 並直接採用(Accept)AI 的產出,終究會遭受反噬。因為你將無法判斷 AI 產出的系統化產品「錯在哪裡」、「隱藏了哪些風險」,甚至連邏輯是否正確、有沒有被 AI「呼攏」都無從得知。

在我的職涯中,曾遇過一位試圖利用Vibe Coding來解決問題的技術主管。他知道 TDD(測試驅動開發),也要求 AI 執行 TDD,但他從未親自審視過 AI 產出的程式碼 — — 殊不知,AI 寫出的 Test Code 只是為了通過測試而存在,近乎是在欺騙他。

隨著沈迷於Ai工具的使用,讓人類的思考開始退步; 本來該是「助手」的東西,結果被當成「大腦替代品」。

認知決定高度

我始終相信一句話:「人類永遠賺不到自己認知範圍以外的錢;如果你僥倖賺到了,終究會憑實力賠回去。」

從Rookie到Junior,一個後端成長的30堂課

Part 31 of 31

“從 Rookie 到 Junior:一個後端成長的 30 堂課” 是一套專為後端新手所設計的成長型技術系列文章。內容以實務為導向,逐步拆解後端工程的核心能力,包括程式語言基礎、架構思維、框架運作原理、業務邏輯設計、資料庫操作、以及常見的開發模式。 本系列的目標是協助讀者從零散的學習堆疊,建立成體系的後端知識框架。讀者能夠理解各語言背後不變的工程思維與設計原則。這套內容旨在讓學習者從「會寫程式」進入「能理解系統設計」的階段,逐步具備勝任 Junior Backend Engineer 的能力。

Start from the beginning

Lesson 26 : 系統韌性的守護者-限流、熔斷與背壓的設計模式

當這幾個名詞出現後,代表我們進到了一個高併發/大流量的系統了。在這個章節中,我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生,限流其實就是字面上的含意,限制流量。 限流的目的是保護「接收方」,確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全

More from this blog

Lesson 26 : 系統韌性的守護者-限流、熔斷與背壓的設計模式

當這幾個名詞出現後,代表我們進到了一個高併發/大流量的系統了。在這個章節中,我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生,限流其實就是字面上的含意,限制流量。 限流的目的是保護「接收方」,確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全

Mar 26, 20262 min read

Lesson 25: 淺談 單體架構、微服務架構與單/多租戶架構

過去我們討論了 要把程式寫在哪、程式要怎麼拆的題目,接下來我們來看看「如何服務不同客戶」,這些架構反映了軟體開發在擴充性與複雜度之間的權衡。 軟體架構深度解析:從系統拆分到商業規模化 在軟體工程的演進中,架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構:系統如何運行(單體 vs. 分散式) 以及 如何服務客戶(單租戶 vs. 多租戶)。

Mar 26, 20262 min read

Lesson 24: 資料庫擴展術-讀寫分離、複寫機制與快取一致性挑戰

為什麼要讀寫分離? 大多數的 Web 應用都是 「讀多寫少」(例如:看文的人多,發文的人少,Heavy Read System)。當所有的請求都塞給同一台資料庫時,磁碟 I/O 和連線數會成為瓶頸。 Master (主庫): 負責寫入 (Insert/Update/Delete),確保數據一致性。 Slave (從庫): 負責讀取 (Select),可以有多個從庫來分擔讀取壓力。 為什麼讀

Mar 25, 20262 min read

面試經驗談 2025-2026

從2025年3月開始,我陸陸續續參與了從新創到上市櫃公司的Senior - Tech Lead的相關面試,其中有不乏 尊重面試者、展現高度專業的企業(公司),當然也有遇到幾場面試鬼故事,這篇文章主要分享我對於軟體工程師面試的方向分享,以及部分鬼故事,以此警惕自己不要成為這樣的面試官。 AI的洪流,改變了SWE的生態 LLM的發展確確實實的影響到了軟體工程師的生態。 過去受限於算力與資料規模,深度學

Mar 23, 20262 min read

Lesson 23: 系統的緩衝區-Queue 佇列與非同步處理 (Asynchronous)

佇列 佇列的實作工具非常多,舉凡AWS SQS、RabbitMQ、Kafka…等。 佇列的特性,其實是一個非常強大的系統緩衝區,應用層面非常廣。 什麼是佇列? 佇列可以想像成,在既有流程中外,有另一個”水管”,來連接原有的資料流(或邏輯過程),其中 呼叫方將資料 推(Push)到水管中,接受方(監聽) 從水管中將資料拉(Pull)出處理 為什麼佇列是「強大的緩衝區」? 在同步處理中,系統像是一

Mar 23, 20262 min read

Bennett's Tech Blog | 後端架構、系統設計

32 posts

來自台灣的軟體工程師,相信軟體可以改變世界