鐵人檔案
AI 寫 Code 越來越快，但我也開始思考：怎麼用 AI 提升開發效率，又不讓自己變成只會接受 AI 給的答案？
這 30 天會以 Android 開發為主，實際嘗試把 AI 用在需求分析、找修改範圍、寫 Code、Review 和測試。同時把 AI 省下來的時間，拿去理解平常寫的 Android Code「為什麼要這樣寫」。
希望最後能整理出一套真的適合自己、也能用在日常開發的 AI 工作方式。
前十天一直在想怎麼讓 AI 在寫 Code 前多理解一點需求，但今天突然想到另一個問題： 就算前面的 Prompt 寫得很好，我最後還是得 Review AI...
昨天整理了 AI 寫完 Code 之後，我會從四個方向 Review： Scope ↓ Requirement ↓ Integration ↓ Code 但整...
昨天整理了一份自己的程式碼檢查清單，主要分成四個方向： 修改範圍 ↓ 需求 ↓ 功能整合 ↓ 程式碼 但整理完之後我想到一個問題。 既然 AI 已經可以幫我寫...
前面幾天大部分都在研究怎麼跟 AI 一起寫 Code，但從今天開始，我想把重點慢慢拉回 Android 本身。 剛好這次拿來實驗的 Project 是我以前自己...
昨天重新看了以前把 Timer 做成 Singleton 的設計，最後其實碰到一個更大的問題： Android 裡的狀態，到底應該放在哪裡？ 如果是 Fra...
昨天整理 ViewModel 時提到一個很重要的差異： Configuration Change ≠ Process Death 平常開發其實很常遇到「狀態要...
昨天整理到 Process Death 時，提到了 SavedStateHandle。 如果 ViewModel 在 Process 被殺掉之後也會消失，那很直...
前幾天一直在看 State 和 Lifecycle，今天想先換個方向，回頭看以前自己寫 Android 時很自然就放進架構裡的一層： Repository。...
前幾天在整理 ViewModel、Process Death 和 State Ownership 時，一直在問同一件事： 這份 State 應該跟誰一起活，又...
昨天整理 Coroutine Scope 時，最後留了一個問題。 假設 Fragment 裡已經這樣寫： viewLifecycleOwner.lifecycl...
