[Перевод] Марсоход, Введение08.11.2016 23:03

1472228826b441d2b4bc5a64978d996f.png

Добро пожаловать в серию статьей «Марсоход», где мы будем использовать следующие практики:

  • Monolithic Repositories — MonoRepo (Монолитные репозитории)
  • Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)
  • Event Sourcing — ES (События как источник)
  • Test Driven Development — TDD (Разработка через тестирование)

В этой вводной статье мы просто обозначим спецификации нашего марсохода.

Примечание. Этот пример является адаптированной для нужд серии статей версией упражнения, представленного на Dallas Hack Club, который сейчас, к сожалению, лежит.

Но сначала, давайте кратко пройдемся по упомянутым выше терминам.

Monolithic Repositories — MonoRepo (Монолитные репозитории)


Монолитный репозиторий представляет собой единое версионированное хранилище, содержащее множество пакетов, связанных друг с другом, имеющие возможность быть разделенными на собственные репозитории, но по причинам удобства сложенные в одном месте.

Этот подход дает нам следующие преимущества:

  • навигация
  • управление зависимостями
  • удобство настройки
  • выполнение тестов

Однако, он также приносит и следующие недостатки:
  • нет жесткого разделения между пакетами
  • ограничения по масштабированию (размер на диске, пропускная способность)
  • отсутствует возможность точечной настройки доступов (пользователь получает все или ничего)

Такие репозитории имеет смысл делать для проектов, которые будут упакованы / выпущены вместе (хотя и самостоятельные репозитории не исключают подобной возможности)

Примечание. Вот несколько ссылок для дополнительного знакомства с монолитными репозиториями:

  • Advantages of a monolithic version control
  • On Monolithic Repositories

Command/Query Responsibility Segregation — CQRS (Сегрегация ответственности на чтение и запись)


CQRS — это о разделении логики «записи» и «чтения», и ее можно применять на многих уровнях, например:
  • read-only микросервисы и микросервисы на запись
  • конечные точки/задачи только для чтения или только для записи
  • разделение ваших моделей на две (опять же, только для чтения и только для записи)

Важно отметить, что CQRS также может быть частично применен в рамках проекта: используйте его только когда это действительно имеет смысл.

Примечание. Вот несколько ссылок о CQRS:

  • Command / Query Responsibility Segregation
  • CQRS
  • Adding the R to CQS: some storage options
  • Clarified CQRS
  • Functional foundation for CQRS / ES
  • Messaging Flavours
  • Avoiding the Mud
  • Do not mistake DDD for CQRS. Yeah but where to start?
  • CQRS/ES
  • Fighting Bottlenecks with CQRS

Event Sourcing — ES (События как источник)


С ES каждое значимое действие записывается как «событие». Отслеживание таких событий обеспечивает следующие преимущества:
  • воспроизведение событий для воссоздания состояния приложения на конкретный момент (откат, повтор, синхронизация)
  • анализ последнего пришедшего состояния (сравнение двух вариантов или поиск кто, что и когда сделал)

Как и с CQRS, важно отметить, что ES также может быть применен _частично_ в проекте: используйте его только когда есть необходимость.

ES часто ассоциируется с CQRS, но они могут использоваться и по отдельности.

Примечание. вот несколько ссылок об ES:

  • Using logs to build a solid data infrastructure or: why dual writes are a bad idea
  • Event Sourcing
  • Practical Event Sourcing
  • CQRS/ES
  • Fighting Bottlenecks with CQRS
  • Functional foundation for CQRS / ES
  • Meeting the Broadway team — talking DDD, CQRS and event sourcing

Test Driven Development — TDD (Разработка через тестирование)


TDD можно свести к трем шагам:
  1. создать тест
  2. написать достаточно кода, чтобы пройти тест (быстрого и грязного, или просто «заставить работать»)
  3. рефакторинг кода (создание чистого, «правильно работающего»)

Написание тестов до кода заставляет нас задуматься о том, как будущий код использовался бы. Это как писать спецификации, но сразу с тремя целями: проектирование, разработка документации и автоматизированная регрессионная проверка.

Такой подход легко позволяет иметь высокое покрытие кода (хотя, строго говоря, все равно нужно проверять все возможные пути кода, не только успешные).

Примечание. вот несколько ссылок о TDD:

  • Straw man TDD
  • Coverage!!!
  • The Failures of «Intro to TDD»
  • TDD, avoid testing implementation details
  • Monogamous TDD
  • When TDD doesn«t work
  • Does TDD really lead to good design?
  • TDD is dead, long live testing
  • What TDD is and is not
  • TDD, where it all went wrong
  • TDD and Complexity
  • Giving up on TDD

Спецификации


Цель этой серии заключается в создании программного обеспечения марсохода, согласно следующим спецификациям:

Марсоход должен будет сначала приземлиться в заданном положении. Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

После всего этого он сможет ездить с помощью инструкций, таких как move_forward (сохраняя ориентацию, но двигаясь по оси x или y) или turn_left/turn_right (сохраняя те же координаты, но изменяя ориентацию).

Время от времени, он будет сообщать текущее местоположение (опять же x и y координаты и ориентацию).

Например, ровер может приземлился на 23, 42, north и затем получить инструкции двигаться вперед дважды, затем налево, а затем снова вперед. Когда будут запрошены координаты, он сообщит 22, 44, west.

Декомпозируем задачу


Из приведенных выше спецификаций, можно выявить как минимум три варианта использования:
  1. Посадка ровера на Марс
  2. Вождение
  3. Запрос местоположения

Что дальше


В следующей статье мы создадим проект и его первый пакет: navigation.

Примечание. Мы будем использовать:

  • PHP 7
  • Composer
  • git
  • phpspec и расширение SpecGen

Комментарии (6)

  • 8 ноября 2016 в 15:09

    +1

    ↑

    ↓

    Марсоход, на php… я уже достал попкорн)

    • 8 ноября 2016 в 16:26

      0

      ↑

      ↓

      ага, и марсоход про плис уже был http://marsohod.org

    • 8 ноября 2016 в 16:35

      +1

      ↑

      ↓

      А вы отчаянный.

  • 8 ноября 2016 в 19:03

    0

    ↑

    ↓

    Положение состоит из координат (X и Y, являющихся целыми числами) и ориентации (строковое значение north, east, west или south).

    И тут внезапно становится ясно, что это всего лишь симулятор марсохода, а не


    Цель этой серии заключается в создании программного обеспечения марсохода, …

    как написано в спецификации.

    • 8 ноября 2016 в 19:25

      0

      ↑

      ↓

      Это реализация популярной каты для практики использования подходов и паттернов

  • 8 ноября 2016 в 22:56

    0

    ↑

    ↓

    конечные точки/задачи только для чтения или только для записи

    По-моему, endpoints не стоит переводить как «конечные точки». Эндпоинты, или урлы апи… исконно русского варианта наверное нет.

© Habrahabr.ru