發表文章

Vibe Coding 心得 - Sparkfit-Lab 開發日誌

我的 Sparkfit-Lab 開發日誌:一場與 AI 協作的 Vibe Coding 實驗 最近我完成了一個名為  Sparkfit Lab  的前端專案,這不僅是一次技術實踐,更是一場關於「Vibe Coding」與 AI 協同開發的深度探索。在這篇文章中,我想與大家分享我是如何利用 Gemini CLI、Cursor AI 等工具,以前所未有的效率打造專案,以及在這趟旅程中的心得與反思。 專案連結: https://github.com/kirinchen/sparkfit-lab 緣起:用 AI 定義專案的「Vibe」 專案的起點,並非一行程式碼,而是一段與 AI 的對話。我首先打開 Gemini,透過對話的方式,共同撰寫了一份詳細的  spec.md  (規格文件)。這不僅是定義功能,更是在設定整個專案的「Vibe」——我希望它帶給使用者什麼樣的感覺?是充滿活力的、激勵人心的,還是專業而簡潔的? 接著,我將這份充滿「Vibe」的規格文件與特製的 Prompt 交給了 Gemini CLI。這一步,是整個開發流程的魔術時刻。 我的 AI 協作工作流:從建築師到雕刻家 我的開發流程像一場由不同樂器組成的協奏曲,每個工具各司其職: Gemini CLI:專案的建築師 我讓 Gemini CLI 讀取  spec.md  與我的核心 Prompt,它便為我搭建起整個專案的基礎框架與核心架構。無論是建立大型功能模組,還是進行結構性的修改,Gemini CLI 就像一位經驗豐富的架構師,快速而準確地將我的藍圖化為實體。 Cursor AI:細節的雕刻家 當大的框架底定後,我便轉向 Cursor AI 進行微調。Cursor 如同一把精巧的雕刻刀,非常適合處理具體的、小範圍的修改。例如,當我想調整某個區塊的版面佈局時,只需在 Cursor 中圈選對應的程式碼,下達「幫我把這裡的排版改成…」之類的明確指令,它便能心領神會地完成任務。 手動編碼:最後的守門員 AI 並非萬能。當 AI 的建議陷入死胡同,或者需要進行一些細微的設定調整時(例如:在特定條件下隱藏某個按鈕),就輪到我的雙手登場了。這時候,開發者自身的技術底蘊就成了專案品質的最後一道防線。 旅程中的重要心得 1. AI 間的「狀態同步」:新時代的開發挑戰 我...

Lombok `@ExtensionMethod` 讓 Java 程式碼優雅變身

  告別冗長的工具類呼叫:用 Lombok  @ExtensionMethod  讓 Java 程式碼優雅變身 身為 Java 開發者,我們都寫過或看過這樣的程式碼: String userInput = " hello world " ; if ( ! StringUtils . isBlank ( userInput ) ) { String processedText = StringUtils . capitalize ( userInput . trim ( ) ) ; System . out . println ( processedText ) ; } int value = NumberUtils . toInt ( someString , 0 ) ; // 失敗時返回預設值 0 這段程式碼完全沒問題,功能正常、邏輯清晰。 StringUtils  和  NumberUtils 。但你不禁會想:如果程式碼能讀起來更像自然語言,更符合物件導向的思維,那該有多好? 如果能像 C# 或 Kotlin 那樣,寫成這樣呢? // 理想中的程式碼 String userInput = " hello world " ; if ( ! userInput . isBlank ( ) ) { // String 本身就有 isBlank() String processedText = userInput . trim ( ) . capitalize ( ) ; // 如果能鏈式呼叫就更棒了! System . out . println ( processedText ) ; } int value = someString . toInt ( 0 ) ; 這就是「擴充方法」(Extension Methods) 的魅力所在。它允許我們在不修改原始類別的情況下,為其「添加」新方法。雖然 Java 語言本身不直接支援此功能,但我們有好朋友  Lombok !透過它的  @ExtensionMethod  註解,我們幾乎可以完美地實現這個夢想。 步驟 2:建立你的「擴充方法」容器 首先...

React 狀態管理的另一種思路:用 Singleton Service 優雅解耦 UI 與資料邏輯

  React 狀態管理的另一種思路:用 Singleton Service 優雅解耦 UI 與資料邏輯 在開發 React 應用時,狀態管理永遠是核心議題。當應用變得複雜,例如需要一個元件(如 Tree View)的選擇去連動另一個元件(如 List View)的內容時,我們常會陷入  props  逐層傳遞(Prop Drilling)的困境,或是需要引入像 Redux、Zustand 這樣功能強大的狀態管理庫。 然而,對於中等規模的應用,或是在想保持輕量、減少依賴的場景下,有沒有更簡潔、更優雅的作法? 答案是肯定的。透過結合兩種經典設計模式—— 單例模式(Singleton) 與 觀察者模式(Observer) ——我們可以打造一個獨立於 React 框架的資料服務層,並透過自定義 Hook(Custom Hook)將它與 UI 元件無縫接軌。 本文將帶你一步步實現這個架構,讓你看到一個 UI 與邏輯徹底解耦的清爽世界。 架構設計:三大核心角色 這個模式主要由三個部分組成,各司其職,完美分工: Singleton Service (大腦 🧠) 這是一個純粹的 TypeScript/JavaScript 類別,負責管理應用的核心狀態資料。 單例模式 確保整個應用中只有「一個」資料實例,成為唯一的「真實來源 (Single Source of Truth)」。 它同時扮演「發布者」的角色,提供  subscribe  方法讓外部訂閱資料變更,並在資料異動時(如新增、刪除),透過  notify  方法通知所有「訂閱者」。 Custom Hook (橋樑 🌉) 這是連接「非 React 世界」的 Service 與「React 世界」的 UI 元件之間的關鍵橋樑。 它封裝了訂閱與取消訂閱的生命週期邏輯。在元件掛載時向 Service 註冊,在卸載時自動取消,完美避免了記憶體洩漏。 當 Service 發出變更通知時,這個 Hook 會更新自身的 state,從而觸發使用它的 React 元件進行重新渲染(re-render)。 React Components (演員 🎭) UI 元件變得非常「單純」。它們不再需要自己管理複雜的共享狀態。 只需呼叫自定義 Hook,就能輕鬆取得最新的資料來進行...