前一天我讓 Claude Code 幫我重構舊 Code，這次我想再進一步，看看它能不能幫我找出專案中的效能問題。

我沒有直接要求它修改 Code，而是先讓它分析：

請幫我分析目前專案的效能問題。

先不要修改任何程式碼，
請檢查：

1. 是否有重複執行的操作
2. 是否有不必要的 Database Query
3. 是否有可以改善的迴圈
4. 是否有可能造成效能問題的 Code
5. 哪些地方最值得優先改善

請說明問題原因，
並提出改善建議。

這次 Claude Code 找到幾個值得注意的地方。

例如 module.py 的 delete，目前會先用 next() 找文章，再使用 ARTICLE_DB.remove() 刪除，等於可能需要掃描兩次資料，時間複雜度為 O(2n)。

另外 list_all 在搜尋文章時，每篇文章都會重新執行 .lower()，當文章數量增加時，會產生額外的 CPU 開銷。

它也發現 list_all 沒有分頁，當文章越來越多時，一次回傳整個 ARTICLE_DB，Response 也會跟著變大。

不過這次最讓我注意的是，Claude Code 並沒有看到問題就全部歸類成「效能問題」。

例如 create 使用 len(ARTICLE_DB)+1 產生 ID，刪除文章後可能造成 ID 重複。這比較屬於正確性問題，而不是單純的效能問題。

另外 ARTICLE_DB 是 module 層級的全域 List，在多 Worker 環境下可能產生資料不一致，這則比較偏向架構與可擴展性問題。

這讓我發現，效能分析不只是找「哪裡跑得慢」，還需要判斷問題真正屬於哪一種類型。

而且 AI 提出的改善建議，也不代表一定要全部修改。

例如密碼雜湊、Database Query 等問題，有些是安全性或正確性的必要成本，不能單純為了速度就把它拿掉。

所以這次我學到的是：

效能優化不是看到可以改的地方就改，而是先找出真正的瓶頸，再判斷改善是否值得。

下一步，我想讓 Claude Code 從效能問題再往前一步，看看它能不能幫我檢查專案中的安全性問題。

明天研究主題:讓 Claude Code 幫我檢查 Code 的安全性