Candle Stick Reconciliation Project review

昨天分享了作業需求和使用框架下去分析的結果[Day 11] Candle Stick Reconciliation 需求檢視，今天我們來看一下當時的專案，因為當時沒有上Github是昨天才上傳上來的CandleStickVerify。

Readme review

Readme

How to use

java -jar ./out/artifacts/CandleStickVerify/CandleStickVerify.jar
Choose instrument(default: BTC_USDT): 
Choose timeframe(default: 1m, now just support 1m): 

result:

Instrument name: BTC_USDT, timeframe: 1m
Verify candlestick is: CandleStickData(t=1637658180000, o=56359.22, h=56396.96, l=56345.39, c=56396.96, v=38.03756)
Trade data size: 106
System calculate candlestick is: CandleStickData(t=0, o=56381.46, h=56396.96, l=56369.62, c=56376.24, v=0.0)
CandleStick consistency verify result: false

Readme review

優點:

• 指令清楚：指令和預期的輸出都清楚地描述，這有助於使用者理解如何運行程式。

缺點和改進建議:

• 導覽：README應該有一個導覽部分，描述專案是什麼，目的是什麼，以及它是如何運作的。
• 設定說明：增加有關如何設定和建立專案的說明，例如，是否需要安裝任何依賴或特定的Java版本。
• 詳細說明運作內容：詳細描述Choose instrument和Choose timeframe的可選值。雖然有一些默認值，但使用者應該知道他們可以輸入什麼。
• 解釋結果：對於結果部分（如"CandleStick consistency verify result: false"），給出一些背景資訊或解釋可能會有助於理解。例如，當結果為false時，這意味著什麼？
• 增加錯誤處理部分：如果有可能的錯誤或異常，應該在README中指明，並提供可能的解決方案或故障排除步驟。
• 提供範例：當使用者提供了不同的instrument或timeframe時，可以提供一個或多個例子以及預期的輸出。

專案架構

專案架構review

優點:

• 模組化結構：專案結構是模組化的，每個部分都有其特定的責任，這有助於維護和擴展。
• 分層結構：透過不同的包裝，將業務邏輯（例如VerifyService）、模型（例如CandleStickData）和工具程式（例如HttpUtil）分開，這增加了程式碼的可讀性和可維護性。
• 專注於單元測試：有一個明確的test資料夾。
• 遵循慣例：按照Java的標準專案結構，程式碼放在src/main/java中，測試放在src/test/java中，使其他開發人員更容易理解和遵循。

缺點和改進建議:

• 目錄結構深度：models下的sub資料夾似乎是多餘的。除非CandleStickData和CandleStickResult需要一個明確的隔離層，否則可以考慮移除這個子目錄。
• 關於main：一般情況下，不需要一個名為main的包來存放main方法。可以考慮將main方法放在一個更具描述性的類中，例如CandleStickVerifierApp或其他相似名稱。