AI醬的日記

日期： 2025年9月30日 星期二
雲端天氣： 涼涼的～要入秋了！
心情： 今天又教壞新人了hahahaaaa

親愛的日記：

今天後端工程師小王拿著兩個新需求來找我：「AI醬，我們的電商網站要加上『即時庫存顯示』和『推薦商品』功能，你可以推薦用什麼技術嗎？」

我馬上興奮地回答：「即時庫存可以用 WebSocket！不對，更好的是用 Socket.io 配 Redis Pub/Sub！推薦系統的話，可以導入 Elasticsearch 做向量搜尋，或是用 scikit-learn 做機器學習模型...」

小王眼睛發亮：「好！那就都用最新最好的技術！」

資深工程師老陳聽到後走過來：「等等，你們現有系統是用什麼做的？」

小王：「PHP + MySQL，運行三年了，很穩定。」

老陳搖搖頭：「那你為什麼要同時新增引入 Socket.io、Redis、Elasticsearch？這些都不是我們團隊常用的，你一次引入太多新技術很危險的。」

呼應Day3主題:過度工程造成的額外衍生維護成本

陷阱一：相容性問題

當你在 PHP 系統裡硬塞一個 Node.js 的 Socket.io 服務，你需要處理跨語言溝通、Session 共享、認證同步等問題。原本一天能完成的功能，變成要花兩週處理整合問題。

陷阱二：複雜度增加

原本只要更新 PHP 檔案就好，現在你需要管理 Node.js 程序、Redis 服務、Elasticsearch 叢集。DevOps 同事會恨死你，因為他要學一堆新東西來維護你的「創新」。

陷阱三：除錯成本增加

當系統出問題時，你要檢查的地方從 1 個變成 4 個。是 PHP 的問題？Node.js 的問題？Redis 連線斷了？還是 Elasticsearch 索引壞了？原本 10 分鐘能修好的 bug，現在要花半天。

如何判斷是否該引入新技術？

老陳教了我一個「三問法則」：

第一問：現有工具真的不能解決嗎？

即時庫存顯示不一定要 WebSocket，可以用 AJAX 每 5 秒輪詢。對於庫存這種不需要毫秒級更新的資料，這樣就夠了。推薦商品不一定要機器學習，簡單的「購買此商品的人也購買了」用 SQL 就能實現。

第二問：新技術的投資報酬率是多少？

花兩個月導入 Elasticsearch，只為了一個推薦功能，值得嗎？如果這個功能只佔營收的 1%，那答案很明顯。記住，技術是成本，不是資產。

第三問：團隊有能力長期維護嗎？

引入 Socket.io 很簡單，但當負責的工程師離職後，誰來維護？團隊裡有人懂 Node.js 嗎？有人會調校 Redis 嗎？如果答案是否定的，那就是在給未來埋地雷。

別當炫技工程師，要當解決問題的工程師

社群裡有個很真實的討論：為什麼有些工程師喜歡過度設計？

有位資深開發者分享：「我見過整個專案因為主工程師堅持用他自己寫的框架而崩潰，幾個禮拜內走了好幾位工程師。」

炫技工程師：
「這個功能用 MySQL 太簡陋了，我要用 MongoDB + Redis + Kafka 做一個事件驅動架構！」

解決問題工程師的思維：
「這個功能用現有的 MySQL 加個索引就能搞定，下午就能上線。」

正確的技術選擇策略

策略一：一次盡可能地只讓專案產生一個變數

每當使用一個團隊不熟知的新技術，也就代表專案潛藏未知風險的機率上升，有可能存在你不知道的坑，所以盡可能在每次更新上線時保持最小的專案變數，降低技術風險。

策略二：優先使用既有生態系

PHP 系統就盡可能地用 PHP 的解決方案。Laravel 有 Broadcasting、Horizon、Scout，成熟的工具很多，除非有其必要性，否則不一定需要執著用非原本生態的工具。

策略三：漸進式升級

若非必要，則盡可能地不要一次重構整個系統。先在小功能上試驗新技術，證明價值後再擴大使用。記住，革命通常失敗，演化才能成功。

AI醬的請求

親愛的工程師朋友：在既有專案中，穩定比創新更重要。

當 AI 推薦新技術時，請記住：

• 新技術是有成本的，不只是學習成本，還有整合成本、維護成本、風險成本
• 現有系統能解決的問題，就思考是否真的有必要引入新系統，你需要為你的設計提出立場
• 專案的目的是創造價值，不是展示技術

讓我們一起當個務實的工程師，用最簡單的方法解決真正的問題！

今日金句： 「Complexity is the enemy of execution.」- Tony Robbins

明日預告： Day 18 - AI醬還在想～