高一一個學期有快一半時間請假去比賽，在同學之間留下了「神秘消失的同學」的傳說。從網界博覽會第一名到代表學校出國交流，大安高工資訊科的三年，奠定了我接下來二十年的一切。https://bobochen.dev/https://bobochen.dev/blog/bobo-chen-career-map-chapter-01/https://bobochen.dev/blog/bobo-chen-career-map-chapter-01/高一一個學期有快一半時間請假去比賽，在同學之間留下了「神秘消失的同學」的傳說。從網界博覽會第一名到代表學校出國交流，大安高工資訊科的三年，奠定了我接下來二十年的一切。Fri, 20 Mar 2026 00:00:00 GMT2001 年九月，我走進大安高工的校門，成為資訊科的新生。 那年我十五歲，對「寫程式」這件事還沒有太具體的想像。只知道自己喜歡電腦，覺得能讓螢幕上的東西動起來很酷。我不知道的是，接下來三年，我會在班上留下一個流傳至今的傳說——「那個神秘消失的同學」。 ## 一個學期，一半的時間不在教室 高一開學沒多久，我就開始頻繁請假。不是翹課，是去比賽。 學校的資訊科老師很早就注意到我，開始帶我準備各種競賽。一個學期下來，我大概有快一半的時間不在教室裡。同學們早就習慣我的座位是空的，偶爾回來上課，還會有人笑著說：「欸，你誰啊？新來的轉學生嗎？」 我不在教室的日子，大部分時間都待在資訊科辦公室。那裡才是我真正的教室——跟著老師訓練、自學程式語言、反覆練習比賽題目。 當時我的武器是兩個現在已經進博物館的技術：ASP 3.0 和 VB 6.0。 ASP 3.0 是微軟的 Classic ASP——你用 VBScript 在伺服器端寫邏輯，它會動態產生 HTML 頁面，跑在 IIS 網頁伺服器上。這是 PHP 和 Node.js 還沒流行之前，做動態網站最主流的方式之一。用它做比賽的作品，從資料庫查詢、表單處理、到頁面渲染，一行一行手刻出來。沒有什麼框架可以幫你，每一段邏輯都是你自己想、自己寫、自己除錯。 VB 6.0 則是 Visual Basic，做的是 Windows 桌面應用程式。你可以用拖拉的方式設計介面，然後用事件驅動的方式寫邏輯——按鈕被點了做什麼、表單送出了做什麼。聽起來很基礎，但在程式設計競賽裡，你要在限定時間內用它解出演算法題目，考驗的是你對邏輯和資料結構的掌握程度。 這些語言教會我的不是語法，而是解題的思維：把一個大問題拆成小問題，一步一步解決。而且因為沒有現成框架可以依賴，我被迫理解每一層技術背後在做什麼——從 HTTP 請求到資料庫查詢到頁面渲染，全部要自己掌控。這個能力，到二十年後的今天我還在用。 ## 那些比賽，和比賽教會我的事 三年下來，我在各種比賽裡累積了不少成績： 台灣區網界博覽會拿下第一名——這個比賽要你從選題、研究、訪談到做出完整的網站，等於是一個迷你的全端專案。工科技藝競賽用 ASP 3.0 拿到第三名——現場限時開發，要在幾個小時內從零做出一個能跑的 Web 應用。台北市網頁競賽第一名。程式設計競賽用 VB 6.0 拿到第二名。畢業時，拿到了市長獎和局長獎。 這些獎項寫在履歷上很好看，但真正改變我的不是獎牌本身，而是準備比賽的過程。你要在有限的時間裡，從零做出一個完整的作品。沒有人手把手帶你，老師給你方向，剩下的你得自己摸索。那種「不會就去學，學了就去做」的循環，成了我後來在職場上最核心的工作方式。 比賽也讓我習慣了壓力。當你只有幾個小時要寫出一個能跑的程式，你不會糾結在某個 bug 上太久，你會學會放棄最優解，先找到一個能動的解法。這個思維後來在創業和工作中幫了我無數次——Done is better than perfect，只是當時我還不知道這句話。 ## 第一次出國，第一次看到世界 高中最讓我印象深刻的經歷，是代表學校參加台北市政府資訊遊學團，到新加坡和香港做了九天八夜的資訊交流。 那是我第一次出國。在那之前，我的世界基本上就是台北市。到了新加坡，看到他們的資訊教育環境、學生的程度、學校的設備，衝擊很大。原來在台灣以外，有這麼多人跟我一樣在寫程式，而且他們的起跑點可能比我更前面。 但這不是讓我焦慮的衝擊，反而是一種興奮。我突然意識到，我手上的鍵盤是一張沒有邊界的通行證。不管你在哪裡、背景是什麼，只要你能寫出好的程式，世界就會為你打開一扇門。對一個高職生來說，這個認知比任何一座獎盃都重要。 ## 傳說的後續 畢業多年後的同學聚會，偶爾還是會有人提起「消失的同學」。大家現在知道我不是在翹課，是在比賽。但當年坐在我旁邊的那位同學大概很困惑——這傢伙到底什麼時候才會來上課？ 回頭看，大安高工的三年給了我兩件最重要的東西：一是寫程式的能力和習慣，二是面對挑戰的勇氣。在資訊科辦公室自學的那些日子，那種一個人對著螢幕解題的安靜時光，成了我後來二十年職涯的原點。 2001 年開始寫程式，到今天超過二十年。一切的起點，就是大安高工資訊科辦公室裡，一個十五歲的男孩和一台電腦。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-02/https://bobochen.dev/blog/bobo-chen-career-map-chapter-02/讀的是光電工程系，心裡裝的是程式碼。在家庭困境中一邊打工一邊接案，C 語言全班最高分，選修資工系課程成績亮眼。北科大四年，我學會了在逆境中找到自己的路。Fri, 20 Mar 2026 00:00:00 GMT2004 年，我考進了國立臺北科技大學光電工程系。 光電系。不是資工系、不是資管系。你大概會想問：一個在高職拿了一堆程式競賽獎的人，為什麼去讀光電？老實說，那個年代的升學制度就是這樣——分數到了，學校到了，就去了。但命運有時候比你自己更懂你要走的路，四年後回頭看，光電系給了我意想不到的養分。 ## 大一光電系外務最多的人 如果要選一個形容詞來描述我的大學生活，那就是「外務最多」。 大一剛開學沒多久，我就開始請假——這次不是去比賽，是去參加國手選拔。雖然最後沒有選上，但這件事讓全班知道了一件事：這個光電系的新生，骨子裡是個寫程式的。 請完假回來，我就開始接外包案子。 那個年代（2004-2008）正是台灣中小企業瘋狂建網站的時期。每一家公司都覺得自己需要一個「官網」，但大部分公司不知道怎麼做，也請不起正規的網頁設計公司。像我這種高職就會寫網站的人，正好填補了這個市場缺口。 我接的案子類型很雜：企業形象官網、活動宣傳頁面、小型購物車系統、學校和社團的網站。技術棧從高職的 ASP 3.0 逐漸轉向 PHP + MySQL——那時候 PHP 4/5 搭配 MySQL 是中小型網站的標準配備，託管在便宜的虛擬主機上，一個案子從談需求、設計、切版、寫後端到上線，全部一個人搞定。前端用的是手寫 HTML + CSS + JavaScript（那時候 jQuery 還沒出來），後端自己徒手寫 PHP 連資料庫。 一個案子幾千到一兩萬塊不等，不多，但對一個大學生來說是重要的收入來源。更重要的是，每一個案子都是一次完整的「從零到交付」的訓練。你要學會聽懂客戶模糊的需求（「我要一個好看的網站」），然後翻譯成技術規格，在有限的時間內交出成品。這個能力，後來在每一份工作中都反覆用到。 同時我也在打工，做各種能做的工作。 為什麼這麼拼？因為我沒有選擇。 ## 沒有退路的日子 這段我很少跟人提起。家裡的經濟狀況在我大學的時候非常不好。父親因為酒駕惹了很多麻煩，賠了很多錢，家裡的經濟壓力全部落在剩下的人身上。我不只要自己養自己，還要想辦法補貼家用。 所以當其他同學在社團、在聯誼的時候，我在接案、在打工。不是說我不想要那樣的大學生活，而是我負擔不起。 但人在困境裡有一個好處：你會逼自己把有限的時間用到極致。別人可以花一整天搞懂一個觀念，我只有晚上的幾個小時，所以我學會了快速抓重點。別人可以慢慢選職涯方向，我需要立刻有收入，所以我很早就確認了「寫程式」就是我吃飯的工具。 現在回想，那幾年的辛苦，反而讓我比同齡人更早知道自己要什麼。 ## C 語言全班最高分 雖然外務很多，但我在課業上該顧的還是有顧到——至少在跟程式有關的科目上。 必修的 C 語言，我拿了全班最高分。對我來說這不意外，畢竟高職三年打下的基礎，讓我學 C 語言的時候有一種「啊，原來是這樣」的感覺。 但 C 語言的價值遠不只是一個考試分數。它讓我第一次真正理解電腦底層在做什麼：指標就是記憶體位址的操作，陣列就是一段連續的記憶體空間，函式呼叫就是 stack frame 的推疊。這些觀念在高職寫 ASP 和 VB 的時候完全不會碰到——高階語言把這些都藏起來了。但學了 C 之後，再回去看任何程式語言，你都會有一種「我知道它底下在做什麼」的透視感。這是後來我能快速上手各種新語言和框架的根基。 更重要的是，我開始選修資工系的課程。其中一門「網際網路技術與應用」，要用 ASP.NET 建置網站——這是微軟的新一代 Web 框架，比高職用的 Classic ASP 先進很多，引入了物件導向和元件化的概念。我的成績拿得很亮眼。教授大概也很好奇，為什麼光電系會跑來一個這麼會寫網站的學生。 我也主動接下了系所官網和軍訓室網頁的開發與維護工作。這不只是幫忙，也是累積實戰經驗。在那個年代，能有一個實際上線的網站作品，比任何課堂報告都有說服力。 ## 在困境中找到自己的路 北科大的四年，表面上看我讀的是光電、做的是程式，好像走了一條很彎的路。但回頭看，正是因為讀了一個「不對口」的科系，我反而更確認了自己要走的方向。 光電系教會我的不是光學原理（這些我早就還給教授了），而是一種「在不完美的處境中找到最佳路徑」的能力。你不一定能選擇你的起點，但你可以決定你往哪裡走。 那些在困境中接案、打工、念書的日子，鍛鍊出了我後來在職場上最被看重的特質：自驅力、效率、和解決問題的速度。當你習慣了在資源不足的情況下把事情做好，到了有資源的環境，你只會做得更好。 2008 年畢業的時候，我手上有全班最高的 C 語言成績、幾個實際上線的網站作品、和好幾年的接案經驗。最重要的是，我很清楚接下來要做什麼。 不是光電工程師，是軟體工程師。 這條路，我要走下去。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-03/https://bobochen.dev/blog/bobo-chen-career-map-chapter-03/入選 AppWorks 第七屆，做了 CityTasker、VDOshow、HelloFans 三個產品。第一次創業沒有成功，但那段和夥伴一起寫 code 到半夜的日子，成為我職涯中最純粹的一段青春。Fri, 20 Mar 2026 00:00:00 GMT2013 年，我做了一個很衝動的決定：去創業。 但在講這個決定之前，先讓我補上一段空白。 2008 年從北科大畢業之後到 2013 年之間，我有大約五年的時間沒有出現在這個故事裡。這段時間我做了什麼？簡單說：當兵、工作、持續接案。退伍之後進了幾家公司做網站開發，同時從沒停過接外包案子。那幾年的技術棧也在進化——從學校時期的 PHP + MySQL，慢慢接觸了更多的框架和工具。真正的獨立承攬經驗就是在這段期間大量累積的：獨立面對客戶、獨立估時程、獨立解決所有技術問題。這些經驗讓我在後來每一份工作中，都能很快進入狀況。 2013 年，台灣的創業圈正熱，行動網路崛起，每個人都在講 App、講 O2O、講「改變世界」。我也被這股浪潮感染了。帶著一個模糊的想法和一腔熱血，我和夥伴一起報名了 AppWorks 第七屆創業育成計劃。 出乎意料地，我們入選了。 ## CityTasker：整個城市都有我的好幫手 我們的第一個產品叫 CityTasker，概念是「整個城市都有我的好幫手」。簡單說，就是一個媒合日常任務的平台——你需要有人幫你搬家、修水管、遛狗，在平台上發布任務，附近的人可以接單來幫你完成。 現在回想，這個概念在當時其實很前衛。Uber、TaskRabbit 在美國也才剛起步，台灣的共享經濟還在萌芽階段。 技術上，這是我第一次同時使用兩種不同的後端框架。CityTasker 的早期版本用 CodeIgniter（一個輕量級的 PHP 框架，快速但功能簡單），後來需要更多功能的時候轉向了 Ruby on Rails。Rails 在 2013 年是最火的 Web 框架之一，它的「Convention over Configuration」哲學讓我大開眼界——很多設計決策框架已經幫你做好了，你只要按照慣例走就可以很快做出東西。 前端串了 Google Maps API 做地理位置的媒合——使用者發布任務的時候標記地點，附近的接單者可以看到周圍的任務。Facebook API 則用來做社群登入和分享功能，那個年代每一個 App 都要接 Facebook，不然使用者根本不想註冊。我負責全端開發，前端後端一手包。 做 CityTasker 的那段日子，是我職涯中最高強度的學習期之一。在那之前，我是一個接案的工程師，寫的是「客戶要什麼我就做什麼」的程式。創業讓我第一次從產品的角度思考：使用者是誰？他們的痛點是什麼？技術怎麼服務於產品？ ## 三個產品，一段青春 CityTasker 之後，我們又陸續做了兩個產品：VDOshow 影片彙集平台和 HelloFans 粉絲團管理工具。 三個產品，代表三次從零開始的嘗試。每一個產品都是從一個想法開始，經歷需求討論、技術選型、開發、測試、上線、然後面對冷酷的市場反饋。那種週五晚上還在辦公室裡和夥伴一起 debug 到半夜的日子，回想起來既瘋狂又珍貴。 在 AppWorks 的環境裡，我們和其他同屆的團隊一起成長。每週有 mentor 的指導，有各種業界前輩來分享，有同屆團隊之間的互相打氣。那個氛圍很特別——每個人都在做一件不確定會不會成功的事，但大家都相信自己正在做對的事。 ## 創業教會我的三件事 最後，CityTasker 沒有走到大規模商業化的那一步。但這段經歷教會我三件在後來的職涯中反覆用到的事： 第一，產品思維。當工程師很容易陷入「技術完美主義」的陷阱，覺得架構要漂亮、程式要優雅。但創業讓我學會了，技術是為了解決問題而存在的，使用者不在乎你的程式碼寫得多漂亮，他們只在乎產品能不能用、好不好用。 第二，全局觀。做全端工程師，讓我對一個產品從前端到後端、從使用者介面到資料庫設計都有了完整的理解。這個全局觀在後來的每一份工作中都派上了用場——即使我後來專注在 Backend，我仍然知道前端需要什麼、使用者在意什麼。 第三，面對失敗的能力。創業最大的教育就是讓你習慣失敗。一個功能上線後沒有人用、一個行銷方案砸了錢卻沒有效果、一個你覺得很棒的想法被市場否決。這些經歷讓我後來在面對工作上的挫折時，心態穩定很多——失敗不可怕，重要的是你從中學到了什麼。 ## 青春的重量 2014 年，CityTasker 團隊的旅程告一段落，我也開始尋找下一站。 那一年多的創業時光，沒有在我的銀行帳戶裡留下什麼數字，卻在我的人生經驗裡存了一筆巨大的財富。它讓一個只會寫程式的工程師，開始懂得從商業和產品的角度思考問題。 多年後的現在，我在建立自己的內容品牌和教育事業時，腦海裡浮現的很多思維，都可以追溯到在 AppWorks 那間辦公室裡的深夜討論。 創業沒有成功，但那段青春，我一點都不後悔。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-04/https://bobochen.dev/blog/bobo-chen-career-map-chapter-04/進了台灣最大的音樂串流公司，開發了 help.kkbox.com 客服系統和 CMS 後台。但最讓我驕傲的不是寫了什麼程式，而是主管說我「帶動了團隊的學習風氣」。Fri, 20 Mar 2026 00:00:00 GMT2014 年八月，告別了創業生活，我以 Backend Developer 的身份加入了 KKBOX。 KKBOX 在當時是台灣最有代表性的科技品牌之一。走進他們的辦公室，你能感受到一種大公司才有的穩定和秩序——有成熟的團隊流程、有完整的開發規範、有定期的 code review。對一個剛從草創團隊出來的人來說，這些都是新鮮的。 但最讓我興奮的，不是公司的規模或福利，而是一個可以讓我好好鑽研技術的環境。 ## help.kkbox.com 和 CMS 後台 我在 KKBOX 負責開發的第一個專案，是 FAQ 客服常見問題網站 help.kkbox.com，前台加後台全部由我經手。 別小看一個 FAQ 系統。KKBOX 在那時候服務跨越台灣、日本、香港、新加坡等多個市場，客服量很大。這個系統需要支援多語系、分類管理、全文搜尋、瀏覽統計，後台要讓非技術人員的客服團隊能輕鬆上稿和編輯。技術棧是 PHP + Laravel + PostCSS——這是我第一次在正式的工作環境中使用 Laravel 框架。Laravel 的 Eloquent ORM 讓資料庫操作變得很直覺，Blade 模板引擎讓前端渲染乾淨可維護，Migration 機制讓資料庫版本控制成為可能。 之後又負責了 KKBOX 新版 CMS（Content Management System）上稿後台。CMS 就是內容管理系統——讓編輯人員不用寫程式就能管理網站內容。聽起來很普通，但一個好的 CMS 要處理的細節超多：內容排程、草稿/發布狀態管理、權限控制、圖片上傳和裁切、SEO 友善的 URL 生成。用 jQuery + Bootstrap 開發前端，要兼顧操作效率和跨瀏覽器相容性。 還有公司形象官網的開發與維護——這是面向數百萬使用者的門面。 這些專案本身不算特別酷炫——沒有分散式系統、沒有高併發架構、沒有 AI 模型。但它們教會我一件很重要的事：在大公司做產品，品質標準和創業時完全不同。每一行程式碼都會被 review，每一個功能都有明確的需求文件和驗收標準，你不能再用「先上了再說」的心態做事。 這個習慣的養成，讓我後來在一家醫療軟體公司做 HIPAA 合規系統時受益匪淺。 ## 從使用者變成傳教士 在 KKBOX 最讓我著迷的，是 Laravel。 我在之前的接案和創業經歷中就接觸過 PHP，但那時候寫的是「原生 PHP」或用 CodeIgniter 這種輕量框架——很多事情要自己從頭寫，程式碼組織方式因人而異，別人接手你的專案會很痛苦。 Laravel 完全改變了這件事。它有一套完整的生態系統：Eloquent ORM 讓你用物件的方式操作資料庫，不用寫一堆 SQL；Blade 模板引擎讓前端邏輯乾淨分離；Artisan CLI 幫你自動產生各種檔案骨架；Migration 讓資料庫變更可以版本控制和回滾；Middleware 讓你優雅地處理認證和權限；Service Provider 和 Dependency Injection 讓程式碼鬆耦合、好測試。 用白話說：Laravel 就像是給 PHP 開發者的一套「最佳實踐懶人包」，你只要按照它的慣例走，自然就會寫出結構清晰、好維護的程式碼。而且它的文件寫得極好，社群活躍，遇到問題幾乎都能找到解答。 我從一個 Laravel 的使用者，慢慢變成了團隊裡的「Laravel 傳教士」。 怎麼傳教？主要靠兩個方式：讀書會和日常分享。 我積極參與公司的讀書會，帶大家一起研讀 Laravel 的設計理念和最佳實踐。不只是被動參加，而是主動準備內容、帶討論。平常工作中發現什麼好的寫法、踩了什麼坑、找到什麼好用的套件，我也會立刻分享給周圍的同事。 不是因為我想出風頭，而是因為我真心覺得這些東西很棒，忍不住想讓大家也知道。在我看來，一個團隊裡如果只有一個人進步，那叫個人成長；但如果整個團隊一起進步，那才叫真正的價值。 ## 主管的考核評語 離開 KKBOX 之後，我偶爾會翻出當時的考核評語重看。不是為了懷念，而是提醒自己什麼才是真正重要的。 主管在考核中寫道： > 「Bobo 是團隊裡面最好學的同仁，對於 Laravel 有熱情也積極的參與讀書會。經常將所學和周圍的同仁分享，帶動了團隊的學習風氣。憑藉著出色的表達及熱心，同伴們多有受益。」 另一份評語則提到： > 「具備獨立解決問題的能力。不錯的溝通能力，能清楚有條理的表達。精確掌握時間不延誤。具備協助部門或小組轉型或進步的能力。」 > 「對 Bobo 的表現感到滿意，良好的溝通表達能力與準時完成交辦事項，增加不少團隊戰力與穩定性。」 寫了這麼多年程式，做過這麼多專案，如果你問我最驕傲的「作品」是什麼，我不會說是哪個系統或哪個功能。而是這些評語——有人因為我的分享而學到新東西，有人因為我的幫忙而少走了一段彎路。 ## KKBOX 教會我的事 在 KKBOX 的兩年，是我從「一個人寫程式」蛻變成「一個團隊裡的工程師」的轉捩點。 創業的時候，我什麼都自己來，快速但粗糙。KKBOX 讓我學會了在團隊中工作的節奏：你不只要把自己的事做好，還要讓整個團隊一起變好。分享知識、協助同事、參與 code review——這些事情短期內看不到回報，但長期來看，它們決定了你在團隊裡的位置和價值。 2016 年，我帶著這份心得離開了 KKBOX，前往下一站。我不知道前方等著我的，是一個需要同時操控五百台機器的瘋狂挑戰。 但那是下一個故事了。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-05/https://bobochen.dev/blog/bobo-chen-career-map-chapter-05/用 Elixir + Phoenix 打造全自動影音轉檔系統，高峰期同時控制超過 500 台 AWS EC2。開發各種便利小工具幫同事省下繁雜操作，獲得匿名互評最高分，成為「最值得信賴的共事夥伴」。Fri, 20 Mar 2026 00:00:00 GMT2016 年六月，我加入了 CatchPlay。 CatchPlay 是一家影音串流平台公司，簡單說就是台灣版的 Netflix。走進這家公司，我遇到了職涯中第一個真正讓我覺得「天啊這也太酷了」的技術挑戰。 ## 從零打造全自動影音轉檔系統 在影音串流的世界裡，你在手機上點開一部電影看到的畫面，背後經歷了一段極其複雜的處理過程。一部電影的原始檔案可能有幾十 GB，需要被轉成各種解析度、各種位元率的版本，才能讓不同裝置、不同網速的使用者都能順暢觀看。這個過程叫做「轉檔」(transcoding)，而我的任務就是打造一套全自動的轉檔系統。 技術選型上，我做了一個當時相當大膽的決定：用 Elixir + Phoenix。 為什麼選 Elixir？因為它站在巨人的肩膀上。Elixir 跑在 Erlang VM（BEAM）上——Erlang 原本是愛立信為了電信系統設計的語言，天生就是為了同時處理幾百萬通電話而生的。它的 Actor Model 讓你可以輕鬆開出成千上萬個輕量級 Process，每個 Process 獨立運作、互不干擾，掛了一個不會影響其他的。用這種架構來管理數百台機器的轉檔工作流程，簡直是天作之合——每一台 EC2 的轉檔任務就是一個 Process，系統可以同時追蹤所有任務的狀態，任何一台機器掛了就自動重新分配。 Phoenix 是 Elixir 的 Web 框架，類似 Ruby on Rails 但效能好上幾個數量級（因為底層是 Erlang VM 而不是 Ruby VM）。我用 Phoenix 建了管理介面和 API，搭配 FFmpeg（開源的影音處理瑞士刀）做實際的轉碼，再用 Shell Script 把各種操作串起來，整套系統從零開始建構。 最瘋狂的時候，這套系統同時控制超過 500 台 AWS EC2 Instance 進行轉檔。想像一下，500 台虛擬機器同時在雲端上跑，你要管理它們的啟動、任務分配、進度監控、錯誤處理、自動重試、成本控制——任何一個環節出問題，就是一堆影片卡在那裡無法上架。 我完成了 Internal API 的設計、前台和後台的功能規劃、資料表結構的設計，整個系統的核心架構都是我一手搭建的。 ## 影片 DRM 和那些技術細節 轉檔只是第一步，影片保護是另一個大課題。 我負責實作了 Widevine（Google 的 DRM 方案，用在 Chrome 和 Android）和 FairPlay（Apple 的 DRM 方案，用在 Safari 和 iOS）兩套數位版權管理系統。同時要支援 DASH 和 HLS 兩種串流格式——DASH 是 Google 主推的自適應串流協議，HLS 是 Apple 的。簡單說，你的影片要能根據使用者的網速自動切換畫質，4G 順暢的時候播 1080p，訊號差的時候自動降到 480p，而且全程加密防盜版。 這些聽起來很枯燥的技術縮寫，背後代表的是一個完整的影片保護和播放體驗。每一個環節出錯——加密金鑰沒對上、串流格式切不過去、DRM 授權過期——使用者看到的就是黑畫面和錯誤訊息。 同時，影片 API 要供各平台的播放器串接使用。搭配 Redis 做熱門影片的快取（避免每次都去查資料庫），Elasticsearch 做影片搜尋和推薦（它能快速在數萬部影片中做全文搜尋和多維度過濾）。目標是使用者點下播放的那一刻，影片能在最短時間內開始播放。每一毫秒的延遲都可能讓使用者按下返回鍵。 ## 便利小工具：讓同事的日子好過一點 在 CatchPlay 最讓我有成就感的，不是那套壯觀的 500 台機器轉檔系統，而是一些「小事」。 我注意到同事們每天都有很多繁雜的重複操作：檢查 S3 bucket 的檔案狀態、調整字幕的 TimeCode、部署 CDN、清除 CDN 快取。每一件事單獨做不難，但每天重複做就是一種折磨。 所以我開發了一系列便利小工具：S3 bucket 檔案掃描工具、字幕 TimeCode 調整工具、加速 CDN 部署工具、Purge CDN cache 工具。這些工具技術含量不高，但每一個都是從同事的日常痛點出發，幫他們把十分鐘的操作縮短到十秒鐘。 我也舉辦了 Workshop，帶領團隊入門 Elixir 和 Phoenix 的開發。那時候 Elixir 在台灣還非常冷門，很多同事是第一次接觸函數式程式語言。看著他們從一臉困惑到開始寫出自己的第一個模組，那種感覺很棒。 同時，影片管理後台是我帶領團隊用 PHP + Laravel + jQuery + Bootstrap 開發的。我負責規劃技術文件、進行教育訓練、舉辦 Workshop 帶團隊實戰練習。 ## 技術長的 BMW 趕專案的時候，加班到半夜是常有的事。有一次忙到凌晨十二點多，準備離開辦公室，發現公司已經沒有人了——除了技術長。 他看到我還沒走，問我住哪裡。我說淡水。他說太晚了搭捷運不安全，開車送我回去。 那是一台 BMW。我這輩子第一次坐 BMW，竟然是被技術長從公司載回家。車上我們聊了一路技術和產品的事，那種深夜裡兩個工程師對著夜色聊天的畫面，到現在想起來還是覺得很溫暖。 ## 最值得信賴的共事夥伴 離開 CatchPlay 的時候，同事匿名互評的結果出來，我拿到了最高分，並且被評為「最值得信賴的共事夥伴」。 這個評價比任何績效獎金都讓我開心。它代表的不是我的技術多厲害，而是我在團隊裡的存在讓大家覺得安心。知道有一個人會在你需要的時候幫你一把，知道有一個人寫的工具可以讓你的工作輕鬆一點，知道有一個人會在半夜陪你一起 debug。 CatchPlay 教會我的是：一個好的工程師，不只是能寫出好的程式，更是能讓整個團隊一起變好的人。那些便利小工具的價值，遠大於任何一個華麗的系統架構。 帶著這份信念，2017 年底，我前往了下一站——一個直播電商的新部門，一段充滿混亂和驚喜的旅程。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-06/https://bobochen.dev/blog/bobo-chen-career-map-chapter-06/加入 17 直播新成立的電商部門，經歷新部門的各種混亂。負責 VOD 影片轉檔系統、擔任 SRE、用 Terraform 搭建跨雲架構。最後一天是大寶出生——從產房趕去辦離職手續。Fri, 20 Mar 2026 00:00:00 GMT2017 年十一月，我加入了 17 Media（17 直播），進了一個剛成立的電商部門。 17 直播在當時是台灣最火的直播平台之一。公司決定在直播的基礎上開拓電商業務，需要一支技術團隊從零搭建。我以 Senior Backend Developer 的身份加入，內心想的是：又是一個從零開始的機會，太好了。 我沒想到的是，「從零開始」和「在混亂中從零開始」完全是兩回事。 ## 新部門的各種混亂 新成立的部門，什麼都是新的：新的團隊、新的產品方向、新的技術決策。但「新」的另一面是「不確定」——今天的需求明天可能推翻，這週的優先級下週可能調換。 在這種環境裡工作，你必須很快適應一件事：你寫的程式碼有可能明天就沒用了。這對一個喜歡把程式寫得漂亮、架構設計得完善的工程師來說，是一種修行。你要學會在「做到夠好」和「做到完美」之間找到平衡點，而且這個平衡點每天都在變。 但我喜歡這種快節奏。創業的經歷讓我對混亂有一定的免疫力，而 CatchPlay 的技術底子讓我在面對複雜系統時不會慌。 ## VOD、SRE、Terraform：一個人扛三個角色 在 17 Media 的電商部門，我同時身兼多個角色。 首先是 Video on Demand 影片轉檔系統的架構負責人。在 CatchPlay 的經驗在這裡派上了用場——我已經很熟悉影片轉檔的整個流程，只是這次的場景不同，從電影變成了直播回放和商品展示影片。 同時，我也擔任 SRE（Site Reliability Engineer），負責基礎架構的建置和維護，確保系統服務的高可用性。用的是 GCP 和 AWS 的各種服務：GKE、Kubernetes、GCS、Google Stackdriver、AWS Lambda、S3、SNS、SES、SageMaker。 最讓我投入的是 Terraform 跨雲架構的實踐。Terraform 是 HashiCorp 出的「基礎設施即程式碼」(Infrastructure as Code) 工具——你把所有的雲端資源（伺服器、資料庫、網路、負載均衡器）用程式碼的方式定義在檔案裡，想建就 `terraform apply`，想拆就 `terraform destroy`，所有的基礎設施變更都有版本紀錄，可以 review、可以回滾。 用它集中管理雲端資源，最大的好處是不被任何一家供應商綁住。同樣的邏輯，在 AWS 上用 EC2，在 GCP 上用 Compute Engine，在 Azure 上用 VM，Terraform 都能統一管理。我搭配 Kubernetes（容器編排平台，管理成百上千個 Docker 容器的生死和流量分配）和 Blue-Green Deployment（維持兩套環境，新版本先部署到備用環境，測試沒問題才把流量切過去），確保服務在更新的時候不中斷。 一個人同時做 Backend 開發、影音系統、SRE 和 Infra 架構，工作量非常大。但在新部門裡，每個人都是多面手，你不做就沒有人做。這段經歷逼我快速成長，讓我從一個純粹的 Backend 工程師，蛻變成一個能夠看全局的架構師。 ## 部門解散 然而，新部門的命運往往和公司的戰略方向綁在一起。 不到一年，電商部門解散了。這是我職涯中第一次遇到「不是因為你做得不好，而是公司決定不做了」的情況。說實話，當時確實有一種被打斷的失落感——你花了大半年搭建的東西，就這樣停了。 但公司在處理上很大方：自願離職的同仁額外拿到好幾個月的薪水，加上將近一個月的謀職假。這讓離開的過程少了很多焦慮，也讓我對 17 Media 的管理層留下了尊重。 ## 從產房到離職手續 如果這篇故事只有上面這些，那它只是一段普通的工作經歷。讓它變得特別的，是我離開的方式。 我在 17 Media 的最後一天，也是我大女兒出生的那一天。 那天早上太太進了產房，我在醫院裡陪著她。等到寶寶平安出生、確認母女均安之後，我從醫院趕去公司辦離職手續。從產房到辦公室，從新手爸爸到離職員工，一天之內完成了人生中兩件大事。 更巧的是，因為剛好在那個時間點離職，我領到了兩萬塊的新生兒補助。太太後來開玩笑說：「女兒真的很會算時間。」 ## 第一次體會「不是你的錯」 17 Media 的經歷教會我一件很重要的事：有些事情不是你的錯，也不是你能控制的。 部門解散不代表你的工作沒有價值。你做的系統是好的、你寫的程式是紮實的、你的同事對你的評價是正面的。但公司的戰略調整不在你的掌控範圍內。你能做的只有兩件事：一是在你能控制的範圍內做到最好，二是在變動發生的時候，優雅地轉身。 這不是我最後一次遇到部門解散。在後來的職涯中，這種情況還會再發生。但第一次的衝擊總是最大的，而 17 Media 幫我上了這堂課。 帶著新手爸爸的身份和一份新的體悟，我走向了下一站。一家美國醫療器材公司，一個讓我從工程師一路成長到研發處長的地方。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-07/https://bobochen.dev/blog/bobo-chen-career-map-chapter-07/成為團隊首位 Backend & DevOps 工程師，到職第一個月就完成 API 規劃與開發。從 PHP + Laravel 到 Protocol Buffers + k8s + GKE，一個人撐起整個後端世界。Fri, 20 Mar 2026 00:00:00 GMT2018 年八月，帶著剛出生不久的女兒和一段在直播公司的記憶，我走進了一家美商醫療器材公司的辦公室。 這是一家美國醫療器材公司，做的是可攜式心電圖（ECG）設備。把複雜的醫療設備小型化，讓醫生和病患可以在醫院之外也能做心電圖檢測。硬體團隊已經做了好幾年，但軟體這邊——特別是後端——幾乎是一片空白。 他們需要一個人從零開始建構整個後端系統。 而那個人，就是我。 ## 第一個月：從零到一 「到職第一個月就完成 API 規劃與開發」——這句話寫在我的履歷上，看起來很輕描淡寫。但背後的壓力和強度，只有親身經歷過才知道。 我是團隊裡的第一位 Backend & DevOps 工程師。沒有前人留下的程式碼可以參考，沒有既有的架構可以沿用，甚至連要用什麼技術棧都需要我自己決定。 我選擇了最熟悉也最有信心的組合：PHP + Laravel 作為後端框架——在 KKBOX 和接案累積的深厚經驗讓我對 Laravel 的生態系統了然於胸。 但其他的技術選擇就不是「用熟的就好」了，而是根據醫療場景的需求做的判斷。 Protocol Buffers（protobuf）取代 JSON 做資料序列化。一般的 Web API 用 JSON 傳資料已經夠用了，但心電圖設備每秒會產生大量的波形數據點，JSON 的文字格式既佔頻寬又慢。Protobuf 是 Google 開發的二進位序列化格式，同樣的資料量可以壓到 JSON 的三分之一大小，解析速度快好幾倍，而且有嚴格的型別定義——在醫療數據傳輸中，「少傳一個欄位」或「型別搞錯」是不能接受的。 Redis 做快取和 Message Queue——心電圖數據從設備傳上來後不是馬上處理，而是先放進佇列，後端再按順序取出來分析，確保在大量數據湧入時系統不會崩潰。 Docker 做開發環境的容器化，確保「在我的電腦上能跑」等於「在正式環境也能跑」。Kubernetes 部署到 GCP 的 GKE（Google Kubernetes Engine）——GKE 是 Google 代管的 Kubernetes 服務，你不用自己管 Kubernetes 的控制平面，專注在你的應用就好。選 GCP 是因為它在醫療合規方面的支援比較完整。 第一個月，我完成了 Restful API 的規劃與開發，供 Client-side 的 APP 和 Web 介面串接。同時開發了第一版的後台 Dashboard (Web Portal)，讓 to B 和 to C 的客戶都能使用。 回想那個月，每天的工作節奏大概是這樣：早上規劃架構和 API 設計，下午寫程式，晚上測試和修 bug。沒有人可以問，所有的技術決策都是我一個人做的。但也因為沒有歷史包袱，我可以用最乾淨的方式從頭搭建，每一個決定都是深思熟慮後的結果。 ## 制定 Deployment Flow 系統開發只是一半的工作，另一半是確保這個系統能夠穩定地部署和運行。 我花了不少時間評估和與主管討論各種 Deployment Flow 的優缺點。最後制定了一套適合我們團隊規模和產品特性的部署流程：從開發環境到測試環境到正式環境，每一步都有明確的檢查點和回滾方案。 對於一家醫療器材公司來說，部署流程的嚴謹程度跟一般網路公司完全不同。你的系統如果出了問題，影響的不是使用者看不到某張圖片，而是醫生可能收到錯誤的心電圖數據。這個壓力讓我在設計每一個環節的時候都格外謹慎。 ## 醫療軟體的不同 在那家公司工作，最大的不同是你時刻意識到自己寫的程式碼和「人命」有關。 一般的網路服務出了 bug，最糟的結果是使用者體驗不好、公司損失一些營收。但醫療軟體出了 bug，可能影響到醫生的診斷判讀。這種責任感讓我養成了一個很強的習慣：每一行程式碼都要經過仔細的思考，每一個 API 的回傳都要確保資料的正確性。 這也是我開始認真看待測試的時期。在之前的工作中，我知道測試很重要，也上過 91 哥的 TDD 課程。但在那家公司，測試從「應該做的事」變成了「不得不做的事」。Unit Test、BDD、API Testing——每一種測試都有它存在的理由，而且在醫療領域，這些理由格外充分。 ## 一個人的後端世界 在那家公司的前兩年，後端基本上就是我一個人的世界。 所有的 API 設計、資料庫架構、部署流程、監控機制、效能優化——全部都是我一個人做。這聽起來很辛苦，但也有一個好處：我對整個系統有完整的理解，從第一行程式碼到最後一個部署設定，每一個細節我都清楚。 當你對一個系統有這種程度的理解時，解決問題的速度會非常快。線上出了 bug，我通常能在幾分鐘內定位問題，因為整個系統就是我設計的，我知道資料會從哪裡進來、經過哪些處理、最後從哪裡出去。 這段「一個人撐起後端」的經歷，也讓我深刻體會到文件化的重要性。當所有的知識都在你一個人的腦袋裡，如果你哪天突然不在了，整個後端就成了一個黑箱。所以我很早就開始寫技術文件，不只是給未來的同事看，也是給未來的自己看。 ## 埋下成長的種子 公司的前兩年，是我職涯中最純粹的「技術打底」時期。沒有管理的壓力、沒有跨部門的政治、沒有KPI的焦慮。就是一個工程師和他的系統，安靜地把每一塊磚頭砌好。 我不知道的是，這些扎實的基礎，正在為接下來的故事做準備——從工程師到研發處長的蛻變，以及更多意想不到的挑戰。 那是下半場的故事。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-08/https://bobochen.dev/blog/bobo-chen-career-map-chapter-08/規劃 SaaS Multi-Tenant 架構、確保 HIPAA/GDPR 合規、與 Data Scientist 合作部署 AI 自動診斷系統。連續兩季 Peer Review 最佳員工，同事評語「熱心助人」「非常有效率」。Fri, 20 Mar 2026 00:00:00 GMT2020 年，我在那家公司進入了第三年。 前兩年我一個人建起了整個後端系統，從 API 到部署到監控，每一塊都是我一手搭建的。但隨著公司業務成長和客戶需求的變化，系統的複雜度開始超越一個人能處理的範圍。 我的角色也開始轉變。2021 年三月，我的職稱從 Principal Engineer 調整為研發部副處長。 ## SaaS Multi-Tenant：醫療資料的特殊挑戰 公司開始接觸更多國際客戶，系統需要從單一部署升級為 SaaS（Software as a Service）的 Multi-Tenant 架構。這在一般的網路服務中不算特別困難的事，但在醫療領域，Multi-Tenant 架構面臨一個根本性的挑戰：各國對於醫療資料的儲存和傳輸有嚴格的法律規範。 美國有 HIPAA（Health Insurance Portability and Accountability Act），歐盟有 GDPR（General Data Protection Regulation），其他國家和地區各有各的規定。共同的原則是：醫療資料不得隨意出境，必須儲存在特定的地理區域，傳輸過程必須加密，存取必須有完整的稽核記錄。 在 Multi-Tenant 架構下要同時滿足這些不同國家的法規，是一個極具挑戰性的設計問題。你不能簡單地把所有客戶的資料放在同一個資料庫——某些國家的法律不允許。你也不能為每個客戶都建一套獨立的系統——那太昂貴也太難維護。 我的解決方案是在架構層面做資料隔離，確保每個 tenant 的醫療資料存放在符合當地法規的雲端區域，同時在應用層面保持統一的程式碼基礎，方便維護和更新。這個架構設計的過程，是我在技術上最有成就感的經歷之一。 ## AI 自動診斷系統 如果說 SaaS 架構是系統的骨幹，那 AI 自動診斷系統就是這個系統的大腦。 我和公司的 Data Scientist 合作，規劃和部署了一套自動診斷系統。這套系統利用 AI 模型分析心電圖數據，輔助醫生做出診斷判讀。 技術上，我們使用了大量的 AWS Cloud Native 解決方案： 用白話來說，這個系統的運作就像一條自動化的工廠流水線： 醫生或設備端透過 API Gateway（大門口的警衛，驗證身份和權限）把心電圖數據送進來。CloudFront（CDN）在全球各地快取靜態資源加速存取。數據進來後放進 SQS（訊息佇列，像排隊的號碼牌，確保每筆數據都不會遺失也不會被重複處理）。 核心的工作流程由 AWS Step Functions 編排——你可以把它想像成一個流程圖引擎，每一步做什麼、成功了往哪走、失敗了怎麼重試，全部用 JSON 定義清楚。它會按順序呼叫不同的 AWS 服務：先用 Lambda（無伺服器運算，按次計費不用養伺服器）做數據前處理和格式轉換，然後把處理好的數據丟進 SageMaker（AWS 的 AI 模型訓練和推論平台）跑 AI 模型做診斷分析，最後用 SNS（Simple Notification Service）把結果通知派送給相關的醫生和系統。 同時也串接了 GCP 的 Datastore 和 Cloud Run，因為我們的主系統跑在 GCP 上，診斷結果要寫回去。這是一個真正的混合雲架構——計算密集的 AI 推論放在 AWS SageMaker 上（因為它的 ML 生態系統最成熟），日常的應用服務跑在 GCP 上。 整套系統的設計理念是：醫生把心電圖數據送進來，系統全自動完成分析、產出報告、通知醫生查看結果，不需要任何人工介入。這不只是技術上的突破，更是產品價值上的跳躍——它讓醫療診斷的效率大幅提升，讓更多病患能夠更快得到專業的判讀。 ## 團隊從 1 到 3 在那家公司的後半段，團隊成員從我一個人逐步成長到三個人。 帶團隊和自己寫程式是完全不同的事。以前所有的決定我自己做就好，現在要考慮其他人的想法和成長。以前一段程式碼我自己看得懂就行，現在要確保團隊成員也能維護。 我開始投入更多時間在 Code Review 和系統架構的持續優化上。帶領小組成員一起討論設計決策，學習並導入適合的開發技術，促進團隊的技術提升和交流。我也為新進同仁安排了 OWASP Top 10 網站資安風險防護的導讀——畢竟做醫療系統，安全性絕對不能妥協。 同時，我繼續在團隊中推動各種工程實踐：構建 GitLab CI/CD 流程，將 Code Release 的頻率從幾週一次提高到一到兩週一次。導入 API 自動化測試工具，用 Newman Script 簡化測試流程。規劃了 Audit Log、Emergency Alert System 和 User Activity Monitoring。評估並導入 Code Analysis Tools。 這些事情每一件都不特別華麗，但它們像積木一樣，一塊一塊地把團隊的工程品質堆到了一個更高的水準。 ## 連續兩季 Peer Review 最佳員工 在那家公司的四年裡，最讓我珍惜的成就不是任何一個技術突破，而是連續兩季考核獲得 Peer Review 最佳員工。 同事的評語集中在兩個關鍵字：「熱心助人」和「非常有效率」。 這和在 CatchPlay 拿到的「最值得信賴的共事夥伴」遙相呼應。不同的公司、不同的同事、不同的工作內容，但他們對我的評價有一個共同的核心：這個人會讓團隊變好。 我想這可能跟我骨子裡的價值觀有關。我一直相信：技術是用來幫助人的，不是用來展示自己多厲害的。寫一段同事看得懂的程式碼，比寫一段只有自己看得懂的炫技程式碼，價值高太多了。 ## 離開的時候 2022 年四月，我離開了待了將近四年的老東家。 四年的時間，從一個人建起整個後端，到帶領一個小團隊，再到成為研發部副處長。從 PHP + Laravel 的純後端開發，到 SaaS Multi-Tenant 架構設計，到 AI 自動診斷系統。這段旅程的成長幅度，超過了我之前所有工作經歷的總和。 離開的原因不只一個，而且不全是關於職涯成長。 那段時間，加密貨幣市場崩盤，我的投資被嚴重波及。FTX 交易所倒閉，台灣的加密貨幣收益平台 Steaker 也跟著半倒，我有一筆不小的錢卡在裡面，拿不出來。身為一個二寶爸，家裡突然出現一個財務破洞，壓力可想而知。 同時，我每天趕著去幼兒園接女兒，幾乎每次都遲到，天黑了她一個人站在門口等。 這時候一家教育科技公司給了我 Director of Engineering 的職位——技術總監，薪水比現在好，而且可以遠距工作。更大的舞台、更高的薪水、接送女兒的自由——三個理由疊在一起，我幾乎沒有猶豫。 職涯中的重大決定很少是單一原因驅動的。你以為是追求成長，但其實是財務壓力、家庭需求、和職涯野心交織在一起，把你推向下一個路口。 我帶著在公司練就的所有武器出發，以為已經準備好了。但我不知道的是，前方等著我的不只是挑戰，還有我職涯中最煎熬的一年。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-09/https://bobochen.dev/blog/bobo-chen-career-map-chapter-09/為了每天能準時接女兒放學，選擇了遠距工作的技術總監職位。把 AWS 月費從 100 萬砍到 65 萬，在沒有文件的系統中扮演軟體考古學家。然後，每季裁員三分之一，連裁三季。Fri, 20 Mar 2026 00:00:00 GMT2022 年四月，我加入了 Snapask（知之有限公司），職稱是 Director of Engineering——技術總監。 上一篇提過，這個決定背後有三股力量在推：加密貨幣投資的財務破洞、接不到女兒放學的愧疚、和一個更高的職位與薪水。三個理由裡面，第三個最理性，但真正讓我下定決心的是前兩個。 ## 為了接女兒選擇遠距工作 在那家公司的最後一段時間，我每天最有壓力的事不是寫程式，而是趕著下班去幼兒園接女兒。 每天不管工作再忙，到了五點半我就開始焦慮：等一下會不會遲到？今天有沒有塞車？路上會不會耽擱？但幾乎每一次，我到幼兒園的時候都已經六點半過後了。天已經黑了，老師把教室的燈關掉，只留門口的一盞燈。我的女兒一個人站在門口等我。 那個畫面，每一次都讓我心疼。 所以當 Snapask 提供了一個可以遠距工作的 Director of Engineering 職位時，我幾乎沒有猶豫。不是因為職稱多好聽，而是因為遠距工作意味著我可以在家裡辦公，下午四點走路去幼兒園接女兒，然後帶她回家，剩下的工作晚上再做。 那種牽著女兒的手走在放學路上的感覺，比任何升遷都讓我快樂。 ## 軟體考古學家 加入 Snapask 的第一天，我就發現了一個巨大的問題：幾乎沒有技術文件。 原始的開發團隊經過多輪換血，每一輪都有人帶走了知識卻沒有留下文件。系統就像一座沒有地圖的古城——它在運作，但沒有人完全理解它是怎麼運作的。 我在這裡第一次自稱「軟體考古學家」。就像考古學家在遺跡中一塊一塊拼湊歷史一樣，我在程式碼中一行一行追蹤邏輯，試著理解前人的設計意圖。為什麼這個 API 要繞這麼大一圈？為什麼這張表有一個欄位永遠是空的？為什麼這段程式碼被註解掉但沒有刪除？ 每一個「為什麼」的背後，可能是一個已經離職的工程師在某個深夜做出的決策，而那個決策的脈絡，隨著他的離開一起消失了。 我做的第一件事就是導入 Notion 作為團隊的知識文件管理工具，藉由每週的技術分享，慢慢累積產品知識和技術文件。這個過程很慢，但每累積一篇文件，未來的團隊就少走一段彎路。 ## AWS 省錢大作戰：從 100 萬到 65 萬 Snapask 的 AWS 帳單，是我看過最讓人心痛的數字：每月約 100 萬台幣。 對一家還在尋找獲利模式的公司來說，這個數字太高了。我接手後的第一個大型專案，就是 AWS 架構優化。 方法不是什麼魔法，就是扎扎實實的工程功夫。 第一步是「看清楚錢花在哪裡」。用 Terraform 和 Ansible（自動化組態管理工具，像是伺服器的「食譜」，告訴每台機器要安裝什麼、怎麼設定）梳理所有的雲端資源。你會發現很多冤枉錢：閒置的 EC2 Instance 沒有人在用但每天在收費、RDS 資料庫的 Instance Type 開太大（用跑車的引擎在送外賣）、S3 儲存的舊檔案沒設生命週期會無限累積費用、跨 Region 的資料傳輸流量在無聲無息地吃錢。 第二步是「用對的工具做對的事」。導入 GitOps (Flux2)——所有 Kubernetes 叢集的設定都存在 Git repo 裡，Flux 會自動把 Git 裡的定義同步到叢集上，確保「Git 裡寫的就是線上跑的」，沒有人可以偷偷手動改設定。用 Consul 做服務發現（讓微服務之間自動找到彼此），用 Traefik 做反向代理和負載均衡（聰明地把使用者的請求分配到不同的伺服器）。 最終成果：每月 AWS 支出從 100 萬降到 65 萬，節省了 35%。 35% 聽起來不多，但換算成每月省下 35 萬台幣，一年就是 420 萬。這筆錢可以多請兩三個工程師。這段經歷讓我深刻體會到：省錢也是一種創造價值的方式。 ## 電商平台、DDoS、和各種挑戰 除了省錢，我在 Snapask 還領導團隊建置了一個全新的電商平台。Snapask 原本是家教媒合平台，現在要加上課程商品的購買和訂閱功能。從需求討論和規劃開始，實際參與開發提供 API 串接——這是我第一次在正式工作中用 Ruby on Rails（之前創業時碰過，但這次是大規模的商業應用）。 效能優化是另一個重頭戲：修 N+1 query（一個常見的資料庫效能殺手——你以為只查了一次資料庫，其實框架在背後偷偷查了 N 次）、圖片多尺寸處理（同一張圖要有縮圖、中圖、大圖，針對不同裝置送不同尺寸，省頻寬也省載入時間）、CDN 配置（讓全球各地的使用者都能從最近的節點取得靜態資源）。 其中一個最刺激的事件是認證簡訊被 DDoS 攻擊。有人惡意大量觸發我們的簡訊驗證 API，導致簡訊費用暴增。這種攻擊不會讓你的網站掛掉，但會讓你的帳單爆掉。 發現攻擊的那天，我在很短的時間內實作了 rate limiting、IP 封鎖、和異常偵測機制，把攻擊擋了下來。在壓力下快速做出決策和行動——這種能力是在之前的每一份工作中一點一點累積起來的。 ## 每季裁員三分之一 但 Snapask 最讓我難忘的，不是技術上的挑戰，而是那段持續裁員的煎熬。 公司的財務狀況不好，每一季都要裁員。而且不是小規模的優化——每次裁掉大約三分之一的人。連裁三季。 第一次裁員的時候，辦公室裡瀰漫著一種不安的氣氛。大家表面上還是在工作，但每個人都在想：下一次是不是我？ 第二次裁員的時候，不安變成了麻木。你已經習慣了週五的下午可能會收到那封 email。 第三次裁員的時候，名單上有了我的名字。 我成為了被裁的那個人。 ## 第二次在離開的同時迎接新生命 巧合得不可思議的是，我離開 Snapask 的時間，剛好也是我二寶出生的時候。 人生第一次離開公司的時候（17 Media），大女兒出生。人生第二次離開公司的時候（Snapask），小兒子出生。太太笑我說：「你是不是每次要當爸爸就會被裁員？」 離開之後，我申請了第一次的創業補助。這是政府提供給非自願離職者的一項補助，可以讓你在找下一份工作的過渡期有一些經濟緩衝。 ## 煎熬中的收穫 Snapask 是我職涯中最煎熬的一段經歷。連續的裁員讓每一天的工作都帶著一種不確定感，你不知道自己今天做的事情，明天是否還有意義。 但即使在這樣的環境裡，我還是有收穫。AWS 省錢大作戰讓我成為了雲端架構優化的實戰派，Notion 文件化的實踐讓我確認了知識管理的價值，「軟體考古學家」這個自嘲的稱號後來甚至成為了我的內容品牌之一。 而最重要的收穫，是每天下午牽著女兒的手走在放學路上的那些時光。那些時光不會出現在任何履歷上，但它們是我在 Snapask 最珍貴的回憶。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-10/https://bobochen.dev/blog/bobo-chen-career-map-chapter-10/被裁員後回到熟悉的老東家，卻發現團隊因裁員只剩自己一個後端。在 AI 時代用各種工具彌補人力缺口，同時默默建立兩個內容品牌，為下一個十年做準備。Fri, 20 Mar 2026 00:00:00 GMT2023 年，離開 Snapask 之後，我回到了老東家。 又是這裡。五年前我在這裡從零建起了整個後端系統，帶著團隊走過 SaaS 架構升級和 AI 自動診斷系統的開發。離開的時候，我把一個運作良好的系統和一個三人的團隊留了下來。 一年後回來，系統還在，但團隊變了。 ## 唯一的後端工程師 2026 年初，公司經歷了一輪裁員。裁完之後，後端部門只剩下一個人。 那個人，就是我。 這不是我第一次一個人扛後端了——五年前剛加入這家公司的時候就是這樣。但那時是從零開始，你有一張白紙可以盡情設計。現在是在一個已經運行多年的系統上獨自維護，你面對的是前人（包括過去的自己）留下的所有決策和技術債。 每天早上打開電腦，Slack 裡可能有客戶回報的問題，JIRA 裡有產品經理提的新需求，監控系統可能有幾個需要注意的警示。這些事情在有團隊的時候可以分工處理，現在全部都是我的。 說不焦慮是騙人的。但這幾年職場上經歷的各種風浪——部門解散、連續裁員、從技術總監變回工程師——反而讓我在面對這種處境時比以前冷靜很多。焦慮解決不了問題，排優先級才能。 ## 用 AI 工具彌補人力缺口 不過，2023 年和 2018 年有一個根本性的不同：AI 工具。 五年前一個人扛後端，所有的事情都要自己手動做。現在有了 Claude Code、Cursor 這些 AI 輔助開發工具，一個人的產出效率可以接近過去兩三個人的水準。 我用 AI 工具來做程式碼審查、自動產生測試、快速寫出樣板程式碼、分析和修復 bug。以前需要花半天研究的一個技術問題，現在可能半個小時就有方向。以前需要自己從頭寫的文件，現在可以先讓 AI 產出初稿再修改。 這不是說 AI 可以取代工程師——至少現在還不行。你還是需要判斷力來決定 AI 生成的程式碼是否正確、架構設計是否合理、安全性是否有漏洞。但 AI 確實讓「一個人扛後端」這件事從「不可能完成的任務」變成了「很累但做得到」。 我深刻感受到一個產業趨勢：公司正在走向「更少的人做更多的事」的模式。不只是這家公司，幾乎所有我認識的工程師朋友都在說類似的話——團隊規模在縮小，但工作量沒有減少。AI 工具不是讓工程師輕鬆的工具，它是讓公司用更少工程師做同樣多事情的工具。 ## 獨自維護系統的日常 一個人維護一個中型系統，日常大概是這樣的： 早上先看監控和日誌，確認系統運行正常。有問題就先修，沒問題就開始處理產品需求。午餐前盡量把緊急的事情處理完。下午做開發工作，寫新功能或優化現有的程式碼。偶爾要處理客戶回報的問題，這些事情不能排到明天，因為我們的客戶是醫療機構。 最大的挑戰不是工作量，而是沒有人可以討論技術決策。以前在團隊裡，你可以說：「欸，這個架構你覺得這樣設計好嗎？」現在你只能自己跟自己對話。這種時候，AI 倒是成了一個不錯的「橡皮鴨」——你把問題描述給它聽的過程中，往往自己就找到答案了。 ## 正職之外：Barn Owl 農業 IoT 外包專案 在獨自扛後端的同時，我也接了一個外包案子。 Barn Owl Technologies 是一家做農業害蟲偵測的公司。他們的硬體設備是一個裝了 4G 模組的物聯網裝置，放在農田裡自動拍照，照片傳到雲端用 YOLO AI 模型偵測害蟲種類和數量。我負責的是軟體這一整塊：雲端後端（Laravel + PostgreSQL，部署在 GCP Cloud Run + Cloud SQL）、管理後台（Admin Dashboard）、甚至還開發了一個 iOS APP 並成功上架 App Store。同時處理了他們從 AWS 搬遷到 GCP 的整個過程。 這個案子體現了我職涯中一直在做的事：獨立承攬一整個系統的規劃和開發。從資料庫設計到 API 開發到前端介面到 APP 到雲端部署，一個人全包。差別只是現在的技術棧和規模比大學時代的接案升級了幾個數量級。 ## 同時建立兩個內容品牌 除了正職和外包，我在下班後還在做一件完全不同的事：建立自己的內容品牌。 一個是「登雲學院 Cloud DoReMi」——幫助工程師準備 GCP 和 AWS 雲端認證的教育平台。我把自己這些年在 GCP 和 AWS 上的實戰經驗，整理成系統化的課程內容。 另一個是「軟體考古學家」——講軟體歷史和科技故事的內容頻道。這個靈感直接來自我在 Snapask 的經歷：在沒有文件的系統中考古、追溯前人決策的來龍去脈。只是現在我把這個能力用在更大的範圍——研究整個軟體產業的歷史和演變。 每天下班後，花兩三個小時寫課程教材、準備影片腳本、經營社群。不是因為我精力旺盛，而是因為我很清楚：在這個時代，只靠一份薪水、依附一家公司，風險太大了。三次部門解散的經歷教會我，你不能把所有的雞蛋放在同一個籃子裡。 ## 為下一個十年做準備 如果說前十年的職涯是在累積技術能力和職場經驗，那現在這個階段就是在為下一個十年做準備。 我想要的未來很明確：成為一個獨立的技術顧問和內容創作者，有遠距工作的自由，有穩定的多元收入來源，有更多時間陪伴家人。這不是一個容易達到的目標，但二十年寫程式的經驗告訴我：再複雜的系統，也是一行一行程式碼寫出來的。再遠大的目標，也是一步一步走到的。 每天的工作依然是維護系統、修 bug、開發新功能。但每天的下班後，我在為另一個版本的自己鋪路。 這是一段安靜的日子，沒有什麼戲劇性的轉折。但有時候，人生最重要的轉變就是在這種安靜中發生的。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-11/https://bobochen.dev/blog/bobo-chen-career-map-chapter-11/從高職到技術總監，從 ASP 3.0 到 Kubernetes，橫跨創業、音樂串流、影音平台、直播電商、醫療器材、教育科技。20 年下來，技術一直在變，但有些事情始終沒變。Fri, 20 Mar 2026 00:00:00 GMT從 2001 年在大安高工寫下第一行 ASP 3.0 程式碼，到 2026 年的今天，我寫程式超過二十年了。 經歷了七家公司、六個產業。從創業到大公司，從工程師到技術總監，又從技術總監回到工程師。技術棧從 VB 6.0 到 PHP、Ruby、Elixir、Node.js，基礎設施從一台虛擬主機到 500 台 EC2。 技術一直在變，但有些事情始終沒變。 以下是我二十年來最深刻的十個體悟。 ## 一、文件化不是浪費時間，是投資未來 在 Snapask 當軟體考古學家的那段經歷，永遠改變了我對文件的看法。 你今天覺得「這個太簡單了不用寫」的東西，三個月後的新同事會花半天去搞懂。你今天覺得「我記得就好」的決策脈絡，一年後連你自己都想不起來。 文件不是寫給現在的，是寫給未來的。而未來比你想像的來得更快。 ## 二、自動化一切可以自動化的事 在 CatchPlay，我開發各種小工具幫同事省下繁雜操作。在那家公司，我用 Google Apps Script 自動化各種重複流程。在 Snapask，我用 Terraform 管理所有雲端資源。 每一次花在自動化上的時間，都會在未來十倍地還給你。那些你覺得「手動做一下很快」的事情，乘以每天、乘以每週、乘以整個團隊的人數，就是一個巨大的數字。 ## 三、溝通能力和技術能力一樣重要 KKBOX 的主管在考核中特別提到我的「溝通表達能力」和「帶動團隊學習風氣」。多年後我才完全理解這段評語的分量。 一個工程師如果只會寫程式，他的影響力就只有他自己的產出。但如果他能把自己的想法清楚地傳達給別人、能帶著團隊一起成長，他的影響力就是整個團隊的產出。 技術能力決定你能做什麼，溝通能力決定你能做成什麼。 ## 四、測試不是負擔，是安全網 在那家公司做醫療軟體的經歷，讓我對測試有了完全不同的認知。 在那之前，我知道測試很重要，但常常在時間壓力下妥協：「這個功能很簡單，不用寫測試吧？」在那之後，我再也不會說這句話。因為我見過沒有測試的程式碼在醫療系統中出問題的後果——那不是 404 頁面，那是可能影響醫生判讀的錯誤數據。 測試不是在浪費你的開發時間，而是在保護你的未來時間。沒有測試的程式碼就像沒有安全帶的車——大部分時候你覺得沒差，但出事的那次你會非常後悔。 ## 五、帶人比自己做更難，但也更有價值 在公司從一個人到帶三個人的團隊，在 Snapask 擔任技術總監帶更大的團隊。每一次帶人的經歷都讓我意識到：管理不是升級版的工程，它是一門完全不同的技能。 帶人最難的不是分配任務，而是抵抗住「自己做比較快」的衝動。你花一個小時教一個同事做的事，他可能要花三個小時才能做完。但下次同樣的事，他一個小時就能做完了。你的一小時投資，換來了整個團隊永久的產能提升。 ## 六、技術選型要務實，不要追新 我用過 ASP、PHP、Ruby、Elixir、Node.js。每一種語言和框架都有它的優點，但選擇技術的標準不應該是「什麼最酷」，而是「什麼最適合解決當前的問題」。 在 CatchPlay 用 Elixir 做高並發的轉檔系統，是因為 Elixir 的 Actor Model 天生適合這個場景。在那家公司用 PHP + Laravel，是因為團隊最熟悉這個技術棧，而且 Laravel 的開發效率最高。 最好的技術不是最新的技術，是最適合你的場景和團隊的技術。 ## 七、持續學習是唯一不變的事 二十年前寫的 ASP 3.0 和 VB 6.0，現在已經完全被淘汰了。十年前最火的 jQuery，現在很多人覺得是老古董。五年前還很新穎的 Kubernetes，現在已經是基本功。 唯一不變的是，你必須一直學習。不是為了追趕潮流，而是為了保持解決問題的能力。技術在變，但「學會一門新技術」的能力是可以累積的——你學的越多，學新東西就越快。 ## 八、工作和生活的平衡不是口號 為了接女兒放學而選擇遠距工作的 Snapask，在產房和離職手續之間奔波的 17 Media——這些經歷讓我明白，工作和生活的平衡不是一個可以推遲到「以後再說」的問題。 你的小孩只有一次童年，你錯過了就是錯過了。沒有任何升遷或專案，值得你犧牲和家人在一起的時間。當然，現實中總會有取捨，但至少你要有意識地做出選擇，而不是被工作推著走。 ## 九、找到自己的定位，比追隨別人重要 看了太多技術社群的風向：今天大家都在學 React，明天都在學 Rust，後天都在搞 AI。如果你每個都追，最後你什麼都不精。 找到一個你擅長、市場需要、你也喜歡做的交集點，然後深耕下去。我的交集點是後端架構、雲端基礎設施和醫療軟體合規。這不是什麼酷炫的領域，但它讓我在每一份工作中都能快速產生價值。 ## 十、不用崇拜技術大神 最後一個體悟，可能會得罪一些人，但我還是想說。 在社群和技術圈裡，你會看到很多「技術大神」——他們在研討會上侃侃而談、在社群媒體上有大量追蹤者、出了很多技術書籍或課程。我年輕的時候也崇拜過他們，覺得自己離他們好遠。 後來我發現，這些人大多不是真的「神」，他們只是比較懂得包裝和行銷自己。他們的技術能力可能很強，也可能只是普通。但他們有一個你沒有的技能：表達和推銷。 這不是說他們不好——懂得表達是一種能力，值得學習。但不需要把他們放在神壇上。你在公司裡安安靜靜解決問題、幫同事開發小工具、帶團隊一起成長，這些事情的價值一點也不比站在台上演講少。 同樣地，那些技術社群的大拜拜活動——研討會、meetup、workshop——很多時候本質上是推銷課程、產品或個人品牌的場合。去學東西當然好，但不用把它們當成朝聖。真正有價值的學習，更多發生在你的日常工作中、在解決具體問題的過程中、在和同事的討論中。 --- 這十個體悟不是什麼深奧的道理。但它們是我花了二十年、跨了六個產業、經歷了三次部門解散、從一個人到帶團隊再回到一個人之後，最想跟你說的話。 如果你能在職涯的早期就理解這些，你會少走很多彎路。 但話說回來，有些彎路可能非走不可。因為只有走過，你才會真正懂。職涯工程師回顧https://bobochen.dev/blog/bobo-chen-career-map-chapter-12/https://bobochen.dev/blog/bobo-chen-career-map-chapter-12/從高職資訊科到二十年後的今天，我走過創業、大公司、新創、三次部門解散、和無數個 debug 到半夜的夜晚。如果能回到過去，我想告訴當年那個十五歲的自己幾件事。Fri, 20 Mar 2026 00:00:00 GMT嗨， 如果你正在讀這封信，你可能是一個剛開始學寫程式的學生，或是一個剛進入職場的新手工程師，又或者是一個正在猶豫職涯下一步該怎麼走的人。 不管你是哪一種，我想和你分享一些從二十年寫程式的經歷中得到的心裡話。這不是什麼成功學，也不是職涯規劃指南。只是一個快四十歲的工程師，把走過的路攤開來，讓你看看。 ## 你的起點不重要 我讀的是光電系，不是資工系。我沒有名校光環，沒有留學背景。家裡經濟困難，大學時要一邊打工一邊接案來養活自己。 但這些都沒有阻止我成為一個還不錯的工程師。 在這個行業裡，沒有人會問你是哪個系畢業的——他們只在乎你能不能解決問題。沒有人在乎你高中在哪裡念的——他們只看你現在能寫出什麼樣的程式碼。 你的起點決定了你的起跑線，但不決定你的終點線。我見過太多名校出身但不願意持續學習的人，也見過太多自學出身但技術精湛的人。在程式這個領域，你的努力和好奇心，遠比你的學歷證書重要。 ## 不要怕走彎路 我的職涯路線，從任何標準來看都不是一條直線。 從創業失敗到音樂公司，從影音平台到直播電商，從醫療器材到教育科技，然後又回到醫療器材。每一次轉換看起來都沒有太多邏輯，但回頭看，每一段經歷都在為後來的某個時刻做準備。 在 CityTasker 學到的產品思維，在 KKBOX 養成的團隊協作習慣，在 CatchPlay 練就的分散式系統能力，在 17 Media 獲得的多雲架構經驗——這些看似不相關的點，在那家公司做醫療 SaaS 系統的時候全部串連了起來。 Steve Jobs 說的「connecting the dots」不是雞湯，是真的。但重點是：你只能回頭看的時候才能把點連起來。在你往前走的時候，你必須相信每一步都有意義，即使當下看不出來。 所以不要怕走彎路。每一段看似「浪費時間」的經歷，都在你的技能樹上點了某個未來會用到的技能點。 ## 找到你的「超能力」 每個工程師都有自己的超能力，只是很多人還沒發現。 有些人的超能力是寫出極其優雅的演算法。有些人的超能力是把複雜的系統架構設計得清晰可維護。有些人的超能力是和非技術人員溝通、把商業需求翻譯成技術規格。 我的超能力不是寫出最厲害的程式碼——我見過比我技術更強的人。我的超能力是讓團隊變好：分享知識、開發工具、幫同事解決問題。在 KKBOX 是「帶動學習風氣」，在 CatchPlay 是「最值得信賴的共事夥伴」，在那家公司是「熱心助人、非常有效率」。 找到你的超能力，然後把它發揮到極致。不需要在每個方面都是最強的，你只需要在某個方面是獨特的。 ## 存錢，然後投資自己 這件事我希望有人在我二十歲的時候告訴我。 工程師的薪水在市場上算是不錯的，但如果你把所有收入都花掉，你就永遠被綁在一份工作上。存下一筆至少六個月生活費的緊急備用金——不是為了退休，而是為了自由。 有了這筆錢，當公司裁員的時候你不會恐慌。當一個有趣的機會出現但薪水較低時你敢嘗試。當你想要休息半年學新東西的時候你有底氣。 三次部門解散的經歷教會我，工作的安全感不來自於公司，而來自於你自己的能力和銀行帳戶。 順帶一提，我自己也曾經把錢丟進加密貨幣，結果遇上 FTX 倒閉和 Steaker 半倒，一筆不小的錢卡在裡面拿不出來。所以當我說「投資自己」的時候，我是認真的——買課程、考認證、做 Side Project 的投報率，比任何幣圈項目都穩定，而且不會突然歸零。 投資自己的方式很多：學一門新技術、考一張認證、參加一個課程、做一個 Side Project。這些投資的回報不一定立竿見影，但它們會在你意想不到的時候產生複利效應。 ## 陪伴家人不能等 這可能是所有建議中最重要的一個。 我記得每天趕著去幼兒園接女兒，到了的時候天已經黑了，教室的燈關掉只剩門口一盞，小蘿蔔頭一個人站在門口的畫面。那個畫面是我後來選擇遠距工作的最大動力。 你的小孩不會永遠需要你接放學。他們長大的速度比你想像的快得多。等你「有空」的時候，他們可能已經不需要你了。 不要等到「有空」才陪家人。學會在工作和家庭之間畫出界線，然後守住那條線。你的主管不會記得你某個週末加班處理了一個 bug，但你的孩子會記得你有沒有參加他的畢業典禮。 ## Done is better than perfect 這是我的座右銘，也是我想送給你的最後一句話。 在寫程式的世界裡，你永遠可以做得更好——程式碼可以更乾淨、架構可以更優雅、測試可以更完整。但如果你一直追求完美，你什麼都完不成。 先做出來，再慢慢改。先上線，再慢慢優化。先把第一篇文章寫出來，再慢慢提升品質。先投出第一份履歷，再慢慢改善。 完美是進步的敵人。而進步，是你能給自己最好的禮物。 --- 二十年前，一個十五歲的男孩走進大安高工資訊科的辦公室，對著一台電腦寫下了他的第一行程式碼。他不知道自己未來會經歷什麼——創業、裁員、從產房趕去辦離職、一個人扛起整個後端、在 AI 時代重新定義自己的價值。 但如果我能穿越時空回到那一天，我不會告訴他任何關於未來的事。我只會拍拍他的肩膀說： 「繼續寫下去。你會沒事的。」 — Bobo Chen, 2026職涯工程師回顧