Bitcoin Trading Bot Design & Static Single Page View Implementation

這個是我做過最有趣的作業，需要設計出一個簡單的交易所套利機器人，要提出系統設計與架構和用Rust簡易實作，和使用React / Next.js依照Figma去刻出一樣的畫面。

作業需求：

作業解析框架：

讀懂需求

確認必須項目:

• 設計一套可以在中心化交易所間套利比特幣價格的簡單交易機器人系統。
• 提供系統設計圖和詳細說明。
• 使用Next.js和React實現一個簡單的靜態頁面。

確認加分項目:

• 詳細的系統設計和設計上的考慮與取捨。
• 優化、模組化和可重用的前端程式碼。

規劃時程 (總時間：一週)

設計時程:

• Day 1-2: 設計交易機器人系統和製作系統圖。

實作時程:

• Day 3-4: 使用Next.js和React開始實現前端界面。

測試時程:

• Day 5: 針對交易機器人系統和前端界面進行測試。

重視Code的質量

SOLID:

Single Responsibility Principle (單一職責原則):

• 交易機器人模組: 每一個模組（如價格查詢、購買、銷售等）應該只有一個改變的原因。例如，負責查詢價格的模組不應該涉及購買或出售邏輯。
• 前端組件: 例如，按鈕組件只應該負責捕捉點擊事件，不應該涉及到資料處理或API呼叫。

Open/Closed Principle (開閉原則):

• 當需要增加新的交易所或新增前端功能時，應能輕鬆地擴展而不修改現有程式碼。

Liskov Substitution Principle (里氏替換原則):

• 如果考慮建立多個交易所的模組，它們都應該可以互換使用而不影響套利邏輯。

Interface Segregation Principle (介面隔離原則):

• 建立小而特定的介面，例如TradeAPI可以被細分為BuyAPI, SellAPI 和 PriceQueryAPI。

Dependency Inversion Principle (依賴反轉原則):

• 套利邏輯應該依賴於交易API的抽象而不是具體的實作，這樣可以輕鬆地替換或增加新的交易所。

Gangs of Four (GoF):

• Strategy Pattern (策略模式):
• 考慮使用策略模式來實現不同的套利策略，讓交易機器人可以輕鬆切換策略。
• Observer Pattern (觀察者模式):
• 如果考慮實時更新交易信息或價格，可以使用觀察者模式讓交易機器人在價格改變時立即作出反應。
• Factory Pattern (工廠模式):
• 當需要建立不同交易所的模組時，使用工廠模式可以簡化模組的創建過程。

選擇合適的工具與技術

選擇習慣的IDE，前端則是使用WebStorm, Rust則是使用Goland，或是剛出preview版本的RustRover

測試你的code

• 為系統設計和前端界面建立單元測試。

建立檢查清單

• [ ] 交易機器人系統設計圖和系統設計討論。
• [ ] 前端靜態頁面的實現。
• [ ] 所有單元測試和整合測試的通過。
• [ ] 確保程式碼遵循SOLID和GoF原則。
• [ ] 提交至Github和相關文件。