發表文章

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，就能輕鬆取得最新的資料來進行...
張貼留言
閱讀完整內容