演算法審查：工程自查清單

引言：「隱藏」的崩潰

大多數 Bug 導致報錯，而演算法 Bug 導致 全線崩潰。 一段在 10 個測試數據上跑得飛快的邏輯，在遇到 10,000 個生產數據時可能需要 10 分鐘。作為開發者或審查者，妳需要在代碼審查 (Code Review) 中培養識別這些模式的「火眼金睛」。

審查者檢查清單

1. 嵌套迴圈陷阱 ($O(N^2)$)

• 模式： 在一個 for 迴圈內部嵌套另一個對同一列表的 for 迴圈。
• 建議： 「我們能不能把內層迴圈換成 雜湊表 查找，把複雜度降到 $O(N)$？」
• 範例： 查重或合併兩個列表。

2. 字串拼接陷阱

• 模式： 在迴圈中使用 str += "..." 構建長字串。
• 風險： 在許多語言（如 Java 或 Python）中，字串是不可變的。每次拼接都會創建新物件，導致 $O(N^2)$ 的記憶體拷貝。
• 建議： 「使用 StringBuilder 或最後一次性 join 陣列。」

3. 無界遞迴

• 模式： 沒有明確深度限制的深層遞迴。
• 風險： 棧溢位 (Stack Overflow)。
• 建議： 「輸入深度有限制嗎？如果沒有，能不能改用 迭代 加棧的方式實現？」

4. 資料庫 N+1 查詢

• 模式： 在迴圈內部調用資料庫查詢。
• 建議： 「進行批量操作！先收集所有 ID，然後用一條 WHERE id IN (...) 語句解決。」

5. 過度排序

• 模式： 為了獲取前 3 名而對整個列表進行排序。
• 建議： 「使用 小頂堆 或 快速選擇 在 $O(N)$ 時間內獲取 Top K。」

開發者的自我修正

在提交 PR 之前，問問自己：

• 「如果 N 是 100,000 會發生什麼？」 (可擴展性)
• 「這段邏輯是確定性的嗎？」 (可靠性)
• 「我使用了正確的資料結構嗎？」 (效率)

典型業務場景

• ✅ CSV 導出： 導出 100 萬行時，不要在記憶體中構建整個陣列。請使用 流式傳輸 (Streaming)。
• ✅ 權限校驗： 不要嵌套迴圈對比每個使用者和每個角色。請使用 位元映射 (Bitmask) 或 Set 集合。

小結：一句話記住它

「代碼審查不僅僅是語法檢查，更是對系統未來的保護。一份演算法清單能確保妳今天寫下的代碼，不會變成妳明天要修的線上事故。」