[Day 9] Food Delivery Platform: API review

app.py

優點：

• 結構清晰：功能以不同的路由方式進行劃分，每個路由下有相應的功能實現，使得程式容易理解和追踪。
• 錯誤處理：程式中使用了try-except-finally結構進行錯誤捕捉，能夠適當地返回錯誤訊息，增加了系統的穩健性。
• 日誌記錄：通過logging模組，對重要操作和可能出錯的地方進行了日誌記錄，有助於後續的問題排查。
• 參數檢查：在一些必要的地方，例如檢查from_time和from_date是否同時存在。
• 資料庫操作分離：將資料庫的操作放在db_util裡，使主程式和資料庫操作解耦，方便後續的維護和擴展。

缺點：

• 重複程式碼：在多個地方出現了類似的code，例如在不同的query_type下的SQL查詢部分有很多相似的地方。下可以進一步封裝函數來減少程式碼重複。
• 錯誤訊息不夠明確：雖然有進行錯誤捕捉，但當前的錯誤訊息相對較為固定和模糊，不易於精確定位問題。
• 資料庫連接管理：在多個路由中，都有手動開啟和關閉資料庫的操作。這部分可以考慮使用上下文管理器或裝飾器來進一步管理資料庫的連接生命週期。
• 參數檢查可以更嚴格：雖然有基本的參數檢查，但仍然可以更加嚴格，例如對日期和時間的格式進行驗證。
• 資料庫操作可能有SQL注入風險：雖然使用了參數化查詢，但在某些地方的SQL組裝時可能仍存在安全隱患。需要確保每一處SQL查詢都使用了參數化查詢以避免SQL注入
• 專案架構拆分：在[Day 7] Food Delivery Platform Code review中提過應該將檔案拆分，會比較好管理與開發，像是app.py只存放啟動Flask的函式，然後controllers存放API interface，services存放API邏輯等。

這邊特別拿出來講，我在第一份工作時，我們的Log會根據API分資料夾儲存，這樣的好處在於很好定位錯誤，如果這個API有問題在查看log時就很方便，但後面的三間公司都把所有log存在同一個檔案，通常都要靠log的關鍵字去parser，兩邊都各有優缺點，我自己是比較喜歡分開存放。

db_util.py

優點：

• 模組化：每個函數執行一個明確的任務（插入、查詢、更新、刪除），這有助於可讀性和覆用性。
• 使用RealDictCursor：這允許查詢結果作為字典返回，這更具可讀性和易於使用。
• 錯誤處理：所有的資料庫操作都有基本的錯誤處理。

缺點：

• SQL拼接方式不安全：直接使用字串拼接來建構SQL語句可能會引起SQL注入攻擊。使用參數化查詢是更好的選擇。
• 過度捕捉例外：通常最好只捕捉你知道如何處理的例外，而不是捕捉所有例外。
• 沒有關閉連線：在執行資料庫操作後，應關閉連線以釋放資源。

utils.py

優點：

• 日期和時間格式化：在返回的資料中進行日期和時間格式化，使其更具可讀性。

缺點:

• HardCode日期時間格式：將日期和時間HardCode成特定的格式可能不具靈活性。
• 不明確的函數參數：limit和offset可能被期望為整數，但在字串連接時它們被當作字串處理。
• 資料庫連接未關閉：在查詢數據庫後，應該關閉資料庫連接以釋放資源。