Clever Geek Handbook

火星探査機、はじめに





火星探査車シリーズへようこそ。ここでは、次のプラクティスを使用します。





この入門記事では、ローバーの仕様を簡単に説明します。



ご注意 この例は、 ダラスハッククラブで発表された一連の記事のニーズに適合した演習のバージョンです。



目次
火星探査機、はじめに

火星探査機、初期化

火星探査機、着陸

火星探査機、着陸座標



しかし、最初に、上記の用語について簡単に説明します。



モノリシックリポジトリ-MonoRepo （モノリシックリポジトリ）



モノリシックリポジトリは、相互に関連する多くのパッケージを含む単一のバージョン管理されたリポジトリであり、独自のリポジトリに分割できますが、便宜上、1つの場所に格納されます。



このアプローチには、次の利点があります。





ただし、次のような欠点もあります。





一緒にパッケージ化/リリースされるプロジェクトに対してこのようなリポジトリを行うことは理にかなっています（ただし、独立したリポジトリはこの可能性を排除しません）



ご注意 モノリシックリポジトリをさらに詳しく調べるためのリンクを次に示します。





コマンド/クエリの責任分離-CQRS （読み取りと書き込みの責任分離）



CQRSは、「書き込み」と「読み取り」のロジックを分離することを目的としており、次のような多くのレベルで適用できます。





CQRSはプロジェクト内で部分的に適用することもできることに注意することが重要です。CQRSは、本当に意味がある場合にのみ使用してください。



ご注意 CQRSに関するリンクを次に示します。





イベントソーシング-ES （ソースとしてのイベント）



ESでは 、重要なアクションはそれぞれ「イベント」として記録されます。 このようなイベントを追跡すると、次の利点があります。





CQRSと同様に、プロジェクトでESを_部分的に適用することもできることに注意することが重要です。必要な場合にのみ使用してください。



ESは多くの場合CQRSに関連付けられていますが 、個別に使用できます。



ご注意 ESに関するリンクを次に示します。





テスト駆動開発-TDD （テストによる開発）



TDDは3つのステップで要約できます。



  1. テストを作成する
  2. テストに合格するのに十分なコードを記述します（迅速かつ汚い、または単に「機能させる」）
  3. コードリファクタリング（クリーンな「適切に動作する」作成）


コードの前にテストを書くと、将来のコードがどのように使用されるかを考えるようになります。 仕様を作成するようなものですが、設計、ドキュメント開発、自動回帰テストという3つの目標を同時に設定します。



このアプローチにより、簡単に高いコードカバレッジを実現できます（厳密には、成功したパスだけでなく、可能なすべてのコードパスをチェックする必要があります）。



ご注意 TDDに関するリンクを次に示します。





仕様書



このシリーズの目標は、次の仕様に従ってローバーソフトウェアを作成することです。



ローバーは最初に所定の位置に着陸する必要があります。 位置は、座標（ X



およびY



、整数）および方向（文字列値north



、 east



、 west



またはsouth



）で構成されます。



このすべての後、彼はmove_forward



（方向を維持するがx



またはy



軸に沿って移動する）またはturn_left



/ turn_right



（同じ座標を維持するが方向を変える）などの指示で乗ることができます。



時々、現在の位置を報告します（再び、 x



とy



座標と向き）。



たとえば、ローバーがnorth



23、42に着陸し、その後、2回前進し、その後左に移動してから再び前進する指示を受け取ったとします。 座標が要求されると、彼は44



、 west



を報告します。



タスクを分解する



上記の仕様から、少なくとも3つのユースケースを特定できます。



  1. ローバーを火星に着陸させる
  2. 運転中
  3. ロケーションリクエスト


次は何ですか



次の記事では、プロジェクトとその最初のパッケージnavigation



を作成します。



ご注意 以下を使用します。







次のパート： ローバー、初期化


More articles:


All Articles