好啦，先承認標題有點浮誇。

它其實也沒有到「上古神獸」的等級，畢竟跟那些還在維護銀行系統的 COBOL 程式碼比起來，我這個專案根本不夠看。它也沒有真的「很硬」，就只是一個我四、五年前寫的 side project。

但對任何一個開發者來說，回頭看自己幾年前寫的程式碼，那種感覺……嗯，你懂的。既熟悉又陌生，總覺得這裡可以更好、那裡可以重寫。這就是這次鐵人賽，我要挑戰的「對手」。

主角登場：它是一個什麼樣的 App？

這個專案的核心是一個 影像互動的運動 App：Jumpr

當初其實是 David 的構思與實作，我只能算是復刻到 Android 上。完成後，它也累積了一些使用者和主要兩個功能（與 iOS 相比差多了），但光是這樣我就累積了一定程度的技術債。

同時由於 Claude Code 生成修正，所以發現有很多步驟如果我沒有紀錄的話，在 AI 生成後產生的問題被我解決完之後，只要我沒有 commit 就再也回不來了，所以我接下來都會開始先做一些紀錄

體質健檢：來看看它的「歷史包袱」

在讓 AI 動手 重構 前，我們得先看看整體架構與裡面的狀況。
所以我讓 Claude Code 幫我查看整個專案，將其整理出文件，下面只放對這次重構來說重要的資訊

架構圖

當初為了技術而技術的債務: ** navigation **

但架構跟使用的工具應該可以說是那個時候的「標準」之一：

• • 整體架構： MVVM (Model-View-ViewModel)
    • 這點還不錯，至少不是混亂的 MVP 或 MVC，讓我們在分層上有了基本的好基礎。

• UI 層： XML + DataBinding

  • 這就是我們這次要剷除的核心目標！ 當年 DataBinding 確實解決了很多 findViewById 的痛苦，但在 Jetpack Compose 面前，它的樣板程式碼、與生命週期的綁定問題，都顯得笨重了。

• 非同步處理： Kotlin Coroutines + Flow

  • 幸好當初就選擇了協程，這讓我們在轉換到 Compose 的非同步資料流時，會相對平順許多。

• 相依性注入 (DI)： Koin

  • 當年為了輕量快速而選擇了 Koin。雖然現在 Hilt 是主流，但 Koin 的存在至少讓模組之間的依賴關係是清晰的。（實際上只是自己一直不太喜歡 Dagger 跟延伸出來的 Hilt）

• 其他主要函式庫：
  其實這個反而不太重要

總體來說，它不是一個無法維護的「屎坑」，但絕對是一個充滿「時代感」，且在 UI 層有大量改進空間的專案。

第一刀，從哪裡開始？一個失敗的嘗試

面對這樣的專案，直接衝進去修改最核心的功能，無疑是自尋死路。

所以，我一開始的盤算是：先從最底層的 Gradle 開始，把它從 Groovy 改為 Kotlin DSL (.kts)，順便引入 Compose 的依賴。

然後，就沒有然後了。

當初花了一兩天，卡在各種 plugin 和奇怪的錯誤上，沒弄個所以然出來，我就果斷放棄了。

這個失敗的嘗試也讓我意識到，如果連環境建置都這麼耗時，那手動重構 UI 層的痛苦指數，只會更高。這也更堅定了我擁抱 AI 來處理這件事的決心。

好了，專案的家底大致上都交代清楚了（應該吧？）。

明天，我們就不再紙上談兵，直接進入如何使用 Claude Code，看看它要如何處理這個專案的轉換！