Мы некоторые сервисы делили пополам, а некоторые объединяли. Не без проблем, но все прошло достаточно гладко.
Самый важный урок — API должен быть доступен через некий центральный роутер (у нас — haproxy), тогда даже дробление/слияние модулей слабо повлияет на видимый api.
Популярный подход — строить архитектуру таким образом, что логические «сервисы» владеют частями предметной области.
У нас примерно так и сделано. По сути, получаются сервисы из монолитов, связанные через REST и AMQP.
Плюсы подобного подхода несомненны: жесткое разделение баз данных, открытый API, которым могут пользоваться не только мы, более быстрые тесты. Раньше прогон всех тестов монолита занимал минут 30, теперь модули собираются параллельно.
Изолированность — это круто, на самом деле. Например, нам пришлось переписать часть модулей с Cassandra на MySql, и это прошло практически незаметно для остальных сервисов, т.к. REST API не поменялся.
Напоминает Akka (не только акторы, но и Future подход). Правда, привычней выглядит возврат Future, а не передача в сервис, что позволяет строить цепочки вызовов типа:
А она там нужна? На мобильном девайсе хабром в принципе пользоваться жутко неудобно (нельзя голосовать, например).
Приложение же раз в неделю стабильно требует заново вводить пароль, отчего я его просто снес.
Спасибо. То есть вот эта фраза из поста «более быстрый доступ к элементам списка в процессе чтения, записи и удаления» на самом деле превращается в «более быстрое добавление/удаление в начале/середине».
Теперь финт ушами: для этих конкретных задач все равно ArrayList подходит больше, если эти операции выразить через добавление в конец и чтение задом наперед. Например, для добавления в середину можно использовать 2 ArrayList, а при чтении объединять.
Потому что стандартные коллекции Java предельно оптимизированы, и используют приемы, недоступные обычному программисту, типа JIT оптимизации.
более быстрый доступ к элементам списка в процессе чтения, записи и удаления
А где тесты на JMH для каждого из случаев? Желательно на разных размерах: 10, 1 000, 1 000 000, 100 000 000
И для разных случаев: sequential access, random access.
Мне бы не хотелось видеть состояние наружу только ради тестирования, даже если бы реализацей такого логгера стал бы внутренний класс, а сам интерфейс бы не регламентировал передачу внутреннего состояния наружу
Реализацией был бы класс в директории src/test
То есть это был бы класс только для тестов. Мне кажется, так было бы проще/чище.
Mockito берёт всю возню с состоянием на себя
Я бы согласился, если бы не простыня кода, чтобы заставить ваш подход работать.
Обычно нет нужды писать какой-то сложный код, чтобы работать с Mockito.
Если же вам пришлось это сделать, то, скорее всего, вы используете Mockito не по назначению.
логгер выступает в роли компонента с write-only семантикой
Не обязательно использовать Mockito для этого. Если логгер — это интерфейс, то можно написать свою имплементацию, которая собирает вызовы в журнал, который торчит наружу. И можно просто проверять через assertThat(logger.getActions(), has(<list of stuff>))
Мне кажется, так будет короче и проще, чем у вас. У вас очень похоже на overengineering.
Mockito утверждает, что это вообще-то антипаттерн https://webcache.googleusercontent.com/search?q=cache:6sm46ByiAY0J:https://monkeyisland.pl/2008/07/12/should-i-worry-about-the-unexpected/+&cd=1&hl=en&ct=clnk&gl=nl&lr=lang_en%7Clang_ru
Лучше тестировать состояние. В вашем примере можно сделать состояние логгера доступным для теста и проверять его с помощью assertThat.
(И еще сильно режут глаза интерфейсы, начинающиеся с I — вы до этого на Delphi писали?)
Мы используем spring-boot и systemd для этих целей. systemd вообще оказалось очень просто — никаких сложных скриптов, конфиг-файл для сервиса занимает 5-10 строк.
У нас в команде был программист, который проповедовал похожий подход — объекты, которые могли ВСЁ — и из базы прочитаться, и по сети передаться, и еще всякое, прямо по Егору.
Выгнали его — за год он написал дико тормозящего монстра, в котором никто не мог разобраться, кроме него.
Мы этого монстра убили и за 1 месяц с нуля переписали 80% функционала, со слоями, DTO и JPA. Оставшиеся 20% допилили за еще месяца 4, причем уже не нужно быть супер опытным программистом, все в команде могут работать с этим кодом, в том числе и новички.
Покрытие тестами лучше, производительность лучше, читаемость лучше, новые люди без проблем разбираются в коде.
Вы видели проект, который Егор приводил в качестве идеала? Как вам?
Самый важный урок — API должен быть доступен через некий центральный роутер (у нас — haproxy), тогда даже дробление/слияние модулей слабо повлияет на видимый api.
У нас примерно так и сделано. По сути, получаются сервисы из монолитов, связанные через REST и AMQP.
Плюсы подобного подхода несомненны: жесткое разделение баз данных, открытый API, которым могут пользоваться не только мы, более быстрые тесты. Раньше прогон всех тестов монолита занимал минут 30, теперь модули собираются параллельно.
Изолированность — это круто, на самом деле. Например, нам пришлось переписать часть модулей с Cassandra на MySql, и это прошло практически незаметно для остальных сервисов, т.к. REST API не поменялся.
Сейчас же я считаю, что это было ошибкой и лучше бы мы использовали Spark и тратили время на его доработку (и помощь сообществу).
Приложение же раз в неделю стабильно требует заново вводить пароль, отчего я его просто снес.
И зачем эта ужасная кнопка слева? На клавиатуре нет кнопки «В начало»?
Теперь финт ушами: для этих конкретных задач все равно ArrayList подходит больше, если эти операции выразить через добавление в конец и чтение задом наперед. Например, для добавления в середину можно использовать 2 ArrayList, а при чтении объединять.
Потому что стандартные коллекции Java предельно оптимизированы, и используют приемы, недоступные обычному программисту, типа JIT оптимизации.
А где тесты на JMH для каждого из случаев? Желательно на разных размерах: 10, 1 000, 1 000 000, 100 000 000
И для разных случаев: sequential access, random access.
Реализацией был бы класс в директории src/test
То есть это был бы класс только для тестов. Мне кажется, так было бы проще/чище.
Я бы согласился, если бы не простыня кода, чтобы заставить ваш подход работать.
Обычно нет нужды писать какой-то сложный код, чтобы работать с Mockito.
Если же вам пришлось это сделать, то, скорее всего, вы используете Mockito не по назначению.
Не обязательно использовать Mockito для этого. Если логгер — это интерфейс, то можно написать свою имплементацию, которая собирает вызовы в журнал, который торчит наружу. И можно просто проверять через assertThat(logger.getActions(), has(<list of stuff>))
Мне кажется, так будет короче и проще, чем у вас. У вас очень похоже на overengineering.
Дело вкуса, однако я за всю карьеру ни разу не сталкивался с IInterface на Java.
Я согласен вот с этими доводами https://stackoverflow.com/questions/541912/interface-naming-in-java
Лучше тестировать состояние. В вашем примере можно сделать состояние логгера доступным для теста и проверять его с помощью assertThat.
(И еще сильно режут глаза интерфейсы, начинающиеся с I — вы до этого на Delphi писали?)
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-first-application-executable-jar
http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-systemd-service
Подскажите, где про это почитать?
Это же антипаттерн по Егору. Вы не уважаете объект. Лезете в его потроха.
А без веры угодить Богу невозможно; ибо надобно, чтобы приходящий к Богу веровал, что Он есть, и ищущим Его воздаёт. Евр.11,6
Выгнали его — за год он написал дико тормозящего монстра, в котором никто не мог разобраться, кроме него.
Мы этого монстра убили и за 1 месяц с нуля переписали 80% функционала, со слоями, DTO и JPA. Оставшиеся 20% допилили за еще месяца 4, причем уже не нужно быть супер опытным программистом, все в команде могут работать с этим кодом, в том числе и новички.
Покрытие тестами лучше, производительность лучше, читаемость лучше, новые люди без проблем разбираются в коде.
Вы видели проект, который Егор приводил в качестве идеала? Как вам?
UPD Для улучшения читаемости я всегда в пул реквестах рекомендую дробить методы на более мелкие, а во многих случаях дробить нужно классы.