Candle Stick Reconciliation Code review

今天開始來Code review這次的作業實作，作業需求可以看這裡：
Day 11 Candle Stick Reconciliation 需求檢視。

com/candlestick/utils/HttpUtil.java

• 重複的Code：apiCandleStickGet 和 apiTradeGet 有很多類似的code。可以取出共用功能，以減少重複的Code。getResponse 和 getTradeResponse 也有一樣的問題。
• 單一責任原則 (SOLID 的 S)：HttpUtil 負責了太多的責任，既要處理 HTTP 通信，又要進行 JSON 解析。可以將 JSON 解析功能分離到另一個Class中，例如 JsonParserUtil。
• 例外處理：如果 HTTP 回應狀態不是200，只是輸出一個錯誤消息。可以提供更多的資訊，例如返回的錯誤訊息。此外，對於 HTTP 或 JSON 解析錯誤，可以拋出自定義的Exception，使上層調用者能更好地處理錯誤。
• 避免使用靜態方法和變量：將方法和變量設置為靜態會限制您進行單元測試和擴展功能。可以考慮使用依賴注入或工廠模式來實例化 HttpUtil。
• HardCode 文字：例如 USER_AGENT、HTTP 方法和內容類型。這些值應存儲在一個設定文件或常量類中，而不是直接HardCode在code裡。
• 關閉資源：可以使用 try-with-resources 來自動關閉 BufferedReader。
• 返回 null：如果 HTTP 回應狀態不是200，會返回 null。這可能會導致NullPointerException。可以使用 Optional 來避免這個問題。

com/candlestick/main/VerifyService.java

• Constant命名：根據 Java 的命名慣例，Constant應該使用全大寫，並用下劃線分隔單字。例如：cryptoUrl 應該改為 CRYPTO_URL。
• Method(方法)的可見性：將不需要為公開的方法設為 private 或 protected，例如 getTradeDetail、getCandlestickFromTradeData 和 verifyCandleStickConsistency。
• switch case 在 getCandlestickFromTradeData 方法中有問題：switch case 實現可能不會正確處理所有情況。例如， tradeDetail.size() 是 2，它將會執行 case 2 但也會執行 case 1。使用 break 來終止每個 case 的執行。
• 避免多次steam操作：在 getCandlestickFromTradeData 方法中，多次遍歷 tradeDetail 來尋找最大和最小值。應一次遍歷來找到這些值，這樣效率更高。
• 時間範圍的HardCode：在 getTradeDetail 方法中，使用了HardCode的 60000 來計算時間範圍。將其作為常量或從參數中獲取。
• 適當的例外處理：callAPI 方法中的任何 HTTP 請求或資料解析都可能失敗。應該提供適當的例外處理來通知使用者任何可能的錯誤。
• 考慮使用 Logger：使用 System.out.printf 來顯示資訊可能不是最佳實踐。使用一個日誌框架（如 SLF4J 或 Log4j）來顯示資訊。
• 適當地組織程式碼：為了使程式碼更具可讀性和維護性，將相關的方法分組在一起，並使用註釋或 JavaDoc 來描述每個方法的功能。
• 嚴格的數據驗證：在驗證方法如 verifyCandleStickConsistency 中，需要更嚴格的數據驗證。

此次的作業心得：這次的作業在很忙的時後開工，以往寫http請求類的都是使用python並沒有用JAVA實現過，雖然那時我是有快四年JAVA開發經驗與一年Python開發經驗，但我幾乎沒有從頭寫起JAVA專案，在整個專案製作的流暢度與對蠟燭圖的概念不熟悉等，導致這次的作業讓我不是很滿意。