И да, многим командам разработки дешевле не обращать на такие проблемы внимания и править неконсистентности вручную силами саппорта, чем устранять эти проблемы на уровне разработки. Потому что проблем этих много, как вы описали, и они сложные, их с наскока не решить. А убытков от них может быть не так и много.
Очень интересный опыт, если в вашем случае это очень важно для бизнеса. Это похоже на хайлоад, там проблемы похожей сложности. И тоже большинство не заморачивается за оптимизацию, пока может себе позволить.
Насколько я разобрался, проблема в общем случае нерешаема. И можно только в каждой конкретной ситуации применять свои решения, которые сработают в частном порядке.
Возможно поэтому нет одного общепринятого решения этой проблемы, и нет такого инструмента, который бы это решение предлагал.
Похоже вы только что переизобрели задачу двух генералов, идемпотентность и дедупликацию.
Сверху можно вам ещё насыпать exactly once semantics, чтоб было совсем хорошо.
Вы говорите, что все вокруг, включая фреймворки, игнорируют эти вопросы. Вроде бы никто не игнорирует, просто вы не по тем ключевикам поискали и не нашли принятых в индустрии подходов.
Советую почитать таки про задачу двух генералов и основные выводы из неё, потому что всё остальное, включая существующие решения, отталкивается от неё.
Код становится легаси тогда, когда непонятно, как он работает. Бывает что это происходит сразу после того, как код написан, бывает в результате многократных изменений.
У такого кода нет тестов, или они плохие.
Если есть нормальные тесты, то можно посмотреть тест кейсы и понять, как оно должно работать. Тесты показывают, как нужно пользоваться компонентом.
И можно менять код, не боясь его сломать, потому что тесты покажут, если что-то перестанет соответствовать требованиям.
Для меня красивый и правильный ответ - это иметь собственное понимание, а не слепо повторять какие-то услышанные фразы.
То есть, даже если я сейчас напишу красивый ответ и вы его повторите мне на собесе, я всё равно буду недоволен, хотя возможно чуть меньше - когда человек повторяет не супер-странные тезисы, а что-то имеющее отношение к действительности, то это уже чуть лучше, хоть и не сильно. Как я это проверяю? Всё просто: я спрашиваю вопросы "а почему так?", "а когда эта штука может пригодиться?", "а когда так делать не надо?". Потому что это как раз важно, когда принимаешь решения в работе. И нагуглить такое в моменте обычно непросто, когда это нужно. Нужно заранее потратить время, чтобы разобраться в инструменте.
Я не считаю, что знаю всё. У других людей может быть другой опыт. Я открыт его принять, если он есть и не совпадает с моим.
Но что я хожу вокруг да около, на такой вопрос я бы ответил коротко так:
Микросервисы - это такой архитектурный стиль, в котором мы разбиваем нашу доменную и техническую логику на довольно мелкие модули, каждый модуль имеет свою осмысленную ответственность и выносится в отдельный сервис. Сервисы инкапсулируют свою внутреннюю реализацию и общаются через выставленный API. По классике это JSON over HTTP, но сейчас это целое поле разных вариантов, синхронных и асинхронных. При этом каждый микросервис является самодостаточным - он разрабатывается, релизится и эксплуатируется как отдельная независимая единица. Микросервисные системы являются распределёнными, и каждый микросервис реализован с пониманием, что его зависимости могут быть периодически недоступны, а данные могут быть неконсистентны.
Нафига оно надо? Главная причина для многих компаний - чтобы эффективно строить разработку с большим количеством команд, при этом имея хорошую скорость поставки изменений. Если у вас 2-3 команды, вам это будет не так инетерсно, если 10 - то уже очень вероятно.
И в целом возможность эксплуатировать микросервисы независимо друг от друга даёт много профита в прозрачности эксплуатации - можно предъявить к сервисам разные требования по SLA, защите персональных данных, отдельно бэкапить данные, тестить нагрузку, собирать логи, обвешивать мониторингом и алертингом.
Третья причина, она важна не так часто как первая, но если у вас сложная разнообразная нагрузка, то легче подстроить микросервисы под профиль этой нагрузки, и в тех местах, где у вас хайлоад, потратить больше денег на более дорогих программистов и другие фреймворки и подходы.
Но я предлагаю смотреть на вопрос шире, и понимать, что микросервисы - это только одна из возможных конфигураций, мы можем X модулей разрабатывать в Y репозиториях и деплоить в Z артефактов в зависимости от нашей потребности, такой взгляд позволяет нам более точно соответствовать требованиям в разных плоскостях.
Самое главное, что я могу пояснить за базар и в каждый вопрос углубиться, объяснить почему так.
Дальше можно разбирать ещё разные плюсы и минусы, их не меньше десятка. Просто для большинства бизнесов они не так важны, сами бизнесы же разные, и какие-то могут получить нехилый бенефит от какой-то особенности микросервисов. Но большинству интересны вот эти 3 - возможность подружить команды разработки между собой, эксплуатировать системы независимо с разными требованиями, и разрабатывать под разную нагрузку.
Просто не всё сразу, я только лет 5 поработав стал этими темами интересоваться. Ни в какие курсы и вузы не впихнуть те знания, до которых доходишь, набираясь опыта и экспертизы.
Модули и микросервисы отличаются одной вещью точно - микросервисы вынуждены общаться по сети со всеми вытекающими, а модули нет.
Ещё микросервисы обычно имеют независимый релизный цикл, а модули могут релизиться все вместе.
Так что нельзя прямо сказать, что они обладают одинаковым набором недостатков. Хотя часть недостатков совпадает, потому что микросервисы - это тоже модули.
Зависимости действительно могут быть неприятной штукой. Но если вы не разбиваете на модули и просто имеете одну общую солянку с кодом, то зависимости никуда не деваются, они всё там же, просто вы их не видите.
Нууу... и да, и нет. Запросы он всё-таки генерирует сам под капотом. Например, мы в коде пишем post.getComments().get(1), а в фоне у нас генерируется и выполняется запрос в БД на получение первого коммента.
Конечно же hibernate не виноват, что всё в итоге тормозит. Но имеем что имеем, иногда чтобы исправить такие проблемы, приходится в сервисе вообще всё взаимодействие с БД рефакторить.
Опять же, нужны знания, чтобы эффективно пользоваться инструментом, и не пользоваться им там, где не надо. Я на собесах бывает спрашиваю, где hibernate использовать не стоит, и очень редко люди это понимают.
В java завезли модульность почти 10 лет назад, она даёт хорошую инкапсуляцию. Но она довольно хардкорная и в обычных проектах она не особо используется, больше в каких-то инфраструктурных, где реально важно инкапсулировать часть классов модуля.
В kotlin тоже есть некоторое подобие - уровень доступа internal. Но тоже пока не встречал, где бы это юзали.
В java изначально всё получше с инкапсуляцией, чем в js, плюс js интерпретируемый, поэтому у них немного разная атмосфера в этом плане. Но общее направление на модульность последние 10 лет точно было. Может кто ещё дополнит.
Кажется, у тех, кто только начинает заниматься архитектурой, как раз не хватает в арсенале инструментов и опыта с ними, поэтому часто делают скорее как где-то увидели, или применяют те решения, которые на слуху. Времени и опыта для взвешенного решения не хватает, поэтому в ход идет выбор по наитию.
Сам делал так же, пока не разобрался в теме. Помню как один раз вкорячил 4 сервиса там, где прекрасно работал бы и 1, потом пришлось переделывать.
Поколение новичков, выбирающих по наитию, никогда не иссякнет, но надеюсь, что хотя бы пройдет этот консенсус в индустрии, что делать микросервисы - это стильно-модно-молодёжно, и вообще уйдет эта ложная дихотомия "монолиты против микросервисов". Может тогда будет меньше ориентира на хайп. Хотя кого я обманываю :)
Дааа, про связность и связанность это оно, но это какие-то магические слова. Мне они не помогают понять, а часто наоборот - как будто сказал "слабая связанность" - и всем всё понятно, выгода очевидна.
Поэтому решил их не вводить, чтобы не плодить сущности и не усложнять статью.
Хотя сами эти концепции вроде бы полезные, и их понимание помогает лучше проектировать.
Это точно устоявшийся термин?
Вряд ли, написал как понимаю, больше из головы. Тоже думаю, что здесь как-то нечётко вышло.
Если серьезно, то я из мира java-энтерпрайза, тут если сразу не начали пилить мега-проект на 5 лет, а просто сделали MVP за полгода, это уже считай повезло. Сразу делают "солидно", с замашкой на успешный проект под рост на годы вперёд.
У нас тут обычно нет практики писать сначала на js, потому что переписывать на другом языке бизнес не готов, когда оно уже работает. Плюс команды не хотят копить техдолг, поэтому сразу делают более менее прилично. Получается правда обычно как всегда :)
И пожалуй среди джавистов мало тех, кто знает js, а ещё меньше тех, кто любит. Хотя мне в целом заходит.
Это ещё не говоря про то, что в энтерпрайзе обычно стандарты на использование языков и технологий, от которых сильно не рекомендуют отходить, плюс общие библиотеки, уже написанные на java.
И конечно и мануальное тестирование, и автотесты, и UI-автотесты - всё это всё ещё нужно. Просто прибегать к ним лучше тогда, когда либо по-другому нельзя, либо когда это реально более выгодно, чем разработчику писать эти тесты. А не просто клепать автотесты на всё без разбора, или мануалить весь регресс, задерживая релиз на дни и недели.
И бывают места, где так делать выгодно, но на среднем энтерпрайз-проекте сейчас этого нужно не так много, особенно среди кучи микросервисов, которые перекладывают json-ы и которые мы релизим независимо.
Спасибо за алаверды на мою статью годичной давности. Я с тех пор получше разобрался в вопросе и попробовал этот подход в новой команде, так что есть что добавить.
Действительно, тестирование переходит к разработчикам, тебе точно не кажется.
Дополню твою картину своей перспективой как разработчик, и со стороны процесса разработки в целом.
Во-первых, сама пирамида тестирования, как на картинке, уже устарела для многих типов современного ПО. Это больше не эталон для всего, а возможно никогда им и не был. Но это отдельная тема, может напишу про это статейку, в двух словах не расскажешь.
Во-вторых, классический подход 10-летней давности, когда разработчик производит код, а тестировщик его проверяет, и они потом радостно кидаются друг в друга багами и фиксами, уж очень неоптимален. На коммуникацию и ожидание друг друга уходит дофига времени, а толку от этого очень мало. Тут явно можно лучше.
В-третьих, даже автотесты тоже дают неприятно длинный цикл обратной связи. Тестировщики обычно уносят все автотесты куда-то в отдельный проект, и тесты гоняются например раз в день по ночам. И опять начинаются разборы по утрам, из-за кого у нас сегодня упали автотесты, заводятся баги, фиксятся и так по кругу. И есть ещё интересные эффекты, которые приносит такой подход.
У тестов, которые пишут разработчики, есть ряд приятных свойств:
- разработчик пишет тест прямо одновременно с задачей, и релизит задачу только когда тесты прошли. То есть не возникает этого порочного большого круга между заливанием кода, его проверкой и исправлением, код уже проверен, всё.
- разработчик может поменять строчку кода, и тут же выполнить полный регресс на своей машине за 5 минут, а не ночью. И опять не надо заводить баги и фиксить их, потому что разработчик пофиксил всё сразу за 5 минут, увидя что тесты не проходят
- тесты меняются вместе с кодом, опять же одновременно
- все тесты проходят, не надо каждый день разбираться с упавшими тестами
- релизный цикл становится гораздо короче
Короче говоря, снимается целый слой суеты, испорченных телефонов, ожидания друг друга. А взамен появляется хорошее покрытие регрессом, который очень хорошо поддерживает проект в долгосрок, и всегда актуален.
Для меня классно работает синергия, когда тестировщик пишет тест-кейсы на задачу ещё перед тем, как я начал писать по ней код, а я реализую его тест-кейсы прямо в тестах сервиса, если это возможно. Это помогает и мне сориентироваться и реализовать всё сразу по требованиям, и тестировщика погружает в задачу ещё до того, как написан код и потрачены дни на разработку.
Согласен, что проверять сам маппер избыточно, если маппинг уже участвует в каком-то тесте.
Сарказма в вашем первом абзаце не понял, кажется вы не уловили смысл моего предыдущего коммента. Смысл не в том, чтобы плодить избыточные тесты, а в том, чтобы то, что должно работать, какими-то тестами проверялось, и не держалось на доверии к авторам библиотеки и к тому, что вы её точно правильно к себе подключили и правильно используете.
И да, будете смеяться, но очень даже в ходу тесты, которые проверяют, какие запросы генерирует ORM, или хотя бы их количество. Потому что иначе вы не гарантируете, что ваш сервис соответствует требованиям, в этом случае нефункциональным. Особенно легко сломать что-то при изменении уже написанного.
Хотя на простых проектах, где нагрузки нет, и нет больших потерь денег из-за подобных ошибок, всё это в общем-то и не нужно.
Если тесты на сервисе, где используется маппер начал падать, то вот вам и сигнал
Вот тут кажется пошла интересная мысль. Что если работа маппера проаеряется косвенно в более крупном тесте, то зачастую этого уже достаточно, чтобы проверить его работу.
а вы пишите тесты на сериализатор в json
В некотором смысле да, например если это rest-контроллер, то нужен тест на основе mockMvc, который проверит, какой именно json возвращает сервер. Вы может быть ожидаете, что это тестировать не нужно и там всё работает само и со 100% гарантией, но на практике это не так. Там стоит проверять например форматы даты-времени, или во что сериализуются какие-то нестандартные типы, типа BigDecimal
проверять совместимость версии должны авторы мапстракта
Вы так будете объяснять бизнесу, когда из-за бага в мапстракте баг будет уже у вас, и на проде будет инцидент? Сомневаюсь, что они оценят :)
И да, многим командам разработки дешевле не обращать на такие проблемы внимания и править неконсистентности вручную силами саппорта, чем устранять эти проблемы на уровне разработки. Потому что проблем этих много, как вы описали, и они сложные, их с наскока не решить. А убытков от них может быть не так и много.
Очень интересный опыт, если в вашем случае это очень важно для бизнеса. Это похоже на хайлоад, там проблемы похожей сложности. И тоже большинство не заморачивается за оптимизацию, пока может себе позволить.
Насколько я разобрался, проблема в общем случае нерешаема. И можно только в каждой конкретной ситуации применять свои решения, которые сработают в частном порядке.
Возможно поэтому нет одного общепринятого решения этой проблемы, и нет такого инструмента, который бы это решение предлагал.
Похоже вы только что переизобрели задачу двух генералов, идемпотентность и дедупликацию.
Сверху можно вам ещё насыпать exactly once semantics, чтоб было совсем хорошо.
Вы говорите, что все вокруг, включая фреймворки, игнорируют эти вопросы. Вроде бы никто не игнорирует, просто вы не по тем ключевикам поискали и не нашли принятых в индустрии подходов.
Советую почитать таки про задачу двух генералов и основные выводы из неё, потому что всё остальное, включая существующие решения, отталкивается от неё.
Код становится легаси тогда, когда непонятно, как он работает. Бывает что это происходит сразу после того, как код написан, бывает в результате многократных изменений.
У такого кода нет тестов, или они плохие.
Если есть нормальные тесты, то можно посмотреть тест кейсы и понять, как оно должно работать. Тесты показывают, как нужно пользоваться компонентом.
И можно менять код, не боясь его сломать, потому что тесты покажут, если что-то перестанет соответствовать требованиям.
У вас есть такой реальный опыт? Звучит как что-то невероятное, я такого ни разу не слышал и не видел.
Пожалуйста, скажи что это вам зачем-то нужно!
Да, справедливо замечено.
Для меня красивый и правильный ответ - это иметь собственное понимание, а не слепо повторять какие-то услышанные фразы.
То есть, даже если я сейчас напишу красивый ответ и вы его повторите мне на собесе, я всё равно буду недоволен, хотя возможно чуть меньше - когда человек повторяет не супер-странные тезисы, а что-то имеющее отношение к действительности, то это уже чуть лучше, хоть и не сильно. Как я это проверяю? Всё просто: я спрашиваю вопросы "а почему так?", "а когда эта штука может пригодиться?", "а когда так делать не надо?". Потому что это как раз важно, когда принимаешь решения в работе. И нагуглить такое в моменте обычно непросто, когда это нужно. Нужно заранее потратить время, чтобы разобраться в инструменте.
Я не считаю, что знаю всё. У других людей может быть другой опыт. Я открыт его принять, если он есть и не совпадает с моим.
Но что я хожу вокруг да около, на такой вопрос я бы ответил коротко так:
Самое главное, что я могу пояснить за базар и в каждый вопрос углубиться, объяснить почему так.
Дальше можно разбирать ещё разные плюсы и минусы, их не меньше десятка. Просто для большинства бизнесов они не так важны, сами бизнесы же разные, и какие-то могут получить нехилый бенефит от какой-то особенности микросервисов. Но большинству интересны вот эти 3 - возможность подружить команды разработки между собой, эксплуатировать системы независимо с разными требованиями, и разрабатывать под разную нагрузку.
Просто не всё сразу, я только лет 5 поработав стал этими темами интересоваться. Ни в какие курсы и вузы не впихнуть те знания, до которых доходишь, набираясь опыта и экспертизы.
А что его нишу сейчас заняло?
Spring Data JPA же на нём работает, и спринг сейчас очень много где.
Модули и микросервисы отличаются одной вещью точно - микросервисы вынуждены общаться по сети со всеми вытекающими, а модули нет.
Ещё микросервисы обычно имеют независимый релизный цикл, а модули могут релизиться все вместе.
Так что нельзя прямо сказать, что они обладают одинаковым набором недостатков. Хотя часть недостатков совпадает, потому что микросервисы - это тоже модули.
Зависимости действительно могут быть неприятной штукой. Но если вы не разбиваете на модули и просто имеете одну общую солянку с кодом, то зависимости никуда не деваются, они всё там же, просто вы их не видите.
Нууу... и да, и нет. Запросы он всё-таки генерирует сам под капотом. Например, мы в коде пишем post.getComments().get(1), а в фоне у нас генерируется и выполняется запрос в БД на получение первого коммента.
Конечно же hibernate не виноват, что всё в итоге тормозит. Но имеем что имеем, иногда чтобы исправить такие проблемы, приходится в сервисе вообще всё взаимодействие с БД рефакторить.
Опять же, нужны знания, чтобы эффективно пользоваться инструментом, и не пользоваться им там, где не надо. Я на собесах бывает спрашиваю, где hibernate использовать не стоит, и очень редко люди это понимают.
М, вот сейчас понял.
В java завезли модульность почти 10 лет назад, она даёт хорошую инкапсуляцию. Но она довольно хардкорная и в обычных проектах она не особо используется, больше в каких-то инфраструктурных, где реально важно инкапсулировать часть классов модуля.
В kotlin тоже есть некоторое подобие - уровень доступа internal. Но тоже пока не встречал, где бы это юзали.
В java изначально всё получше с инкапсуляцией, чем в js, плюс js интерпретируемый, поэтому у них немного разная атмосфера в этом плане. Но общее направление на модульность последние 10 лет точно было. Может кто ещё дополнит.
Кажется, у тех, кто только начинает заниматься архитектурой, как раз не хватает в арсенале инструментов и опыта с ними, поэтому часто делают скорее как где-то увидели, или применяют те решения, которые на слуху. Времени и опыта для взвешенного решения не хватает, поэтому в ход идет выбор по наитию.
Сам делал так же, пока не разобрался в теме. Помню как один раз вкорячил 4 сервиса там, где прекрасно работал бы и 1, потом пришлось переделывать.
Поколение новичков, выбирающих по наитию, никогда не иссякнет, но надеюсь, что хотя бы пройдет этот консенсус в индустрии, что делать микросервисы - это стильно-модно-молодёжно, и вообще уйдет эта ложная дихотомия "монолиты против микросервисов". Может тогда будет меньше ориентира на хайп. Хотя кого я обманываю :)
Дааа, про связность и связанность это оно, но это какие-то магические слова. Мне они не помогают понять, а часто наоборот - как будто сказал "слабая связанность" - и всем всё понятно, выгода очевидна.
Поэтому решил их не вводить, чтобы не плодить сущности и не усложнять статью.
Хотя сами эти концепции вроде бы полезные, и их понимание помогает лучше проектировать.
Вряд ли, написал как понимаю, больше из головы. Тоже думаю, что здесь как-то нечётко вышло.
Да вот это и было в двух словах к чему пришёл :)
Если серьезно, то я из мира java-энтерпрайза, тут если сразу не начали пилить мега-проект на 5 лет, а просто сделали MVP за полгода, это уже считай повезло. Сразу делают "солидно", с замашкой на успешный проект под рост на годы вперёд.
У нас тут обычно нет практики писать сначала на js, потому что переписывать на другом языке бизнес не готов, когда оно уже работает. Плюс команды не хотят копить техдолг, поэтому сразу делают более менее прилично. Получается правда обычно как всегда :)
И пожалуй среди джавистов мало тех, кто знает js, а ещё меньше тех, кто любит. Хотя мне в целом заходит.
Это ещё не говоря про то, что в энтерпрайзе обычно стандарты на использование языков и технологий, от которых сильно не рекомендуют отходить, плюс общие библиотеки, уже написанные на java.
И конечно и мануальное тестирование, и автотесты, и UI-автотесты - всё это всё ещё нужно. Просто прибегать к ним лучше тогда, когда либо по-другому нельзя, либо когда это реально более выгодно, чем разработчику писать эти тесты. А не просто клепать автотесты на всё без разбора, или мануалить весь регресс, задерживая релиз на дни и недели.
И бывают места, где так делать выгодно, но на среднем энтерпрайз-проекте сейчас этого нужно не так много, особенно среди кучи микросервисов, которые перекладывают json-ы и которые мы релизим независимо.
Спасибо за алаверды на мою статью годичной давности. Я с тех пор получше разобрался в вопросе и попробовал этот подход в новой команде, так что есть что добавить.
Действительно, тестирование переходит к разработчикам, тебе точно не кажется.
Дополню твою картину своей перспективой как разработчик, и со стороны процесса разработки в целом.
Во-первых, сама пирамида тестирования, как на картинке, уже устарела для многих типов современного ПО. Это больше не эталон для всего, а возможно никогда им и не был. Но это отдельная тема, может напишу про это статейку, в двух словах не расскажешь.
Во-вторых, классический подход 10-летней давности, когда разработчик производит код, а тестировщик его проверяет, и они потом радостно кидаются друг в друга багами и фиксами, уж очень неоптимален. На коммуникацию и ожидание друг друга уходит дофига времени, а толку от этого очень мало. Тут явно можно лучше.
В-третьих, даже автотесты тоже дают неприятно длинный цикл обратной связи. Тестировщики обычно уносят все автотесты куда-то в отдельный проект, и тесты гоняются например раз в день по ночам. И опять начинаются разборы по утрам, из-за кого у нас сегодня упали автотесты, заводятся баги, фиксятся и так по кругу. И есть ещё интересные эффекты, которые приносит такой подход.
У тестов, которые пишут разработчики, есть ряд приятных свойств:
- разработчик пишет тест прямо одновременно с задачей, и релизит задачу только когда тесты прошли. То есть не возникает этого порочного большого круга между заливанием кода, его проверкой и исправлением, код уже проверен, всё.
- разработчик может поменять строчку кода, и тут же выполнить полный регресс на своей машине за 5 минут, а не ночью. И опять не надо заводить баги и фиксить их, потому что разработчик пофиксил всё сразу за 5 минут, увидя что тесты не проходят
- тесты меняются вместе с кодом, опять же одновременно
- все тесты проходят, не надо каждый день разбираться с упавшими тестами
- релизный цикл становится гораздо короче
Короче говоря, снимается целый слой суеты, испорченных телефонов, ожидания друг друга. А взамен появляется хорошее покрытие регрессом, который очень хорошо поддерживает проект в долгосрок, и всегда актуален.
Для меня классно работает синергия, когда тестировщик пишет тест-кейсы на задачу ещё перед тем, как я начал писать по ней код, а я реализую его тест-кейсы прямо в тестах сервиса, если это возможно. Это помогает и мне сориентироваться и реализовать всё сразу по требованиям, и тестировщика погружает в задачу ещё до того, как написан код и потрачены дни на разработку.
Согласен, что проверять сам маппер избыточно, если маппинг уже участвует в каком-то тесте.
Сарказма в вашем первом абзаце не понял, кажется вы не уловили смысл моего предыдущего коммента. Смысл не в том, чтобы плодить избыточные тесты, а в том, чтобы то, что должно работать, какими-то тестами проверялось, и не держалось на доверии к авторам библиотеки и к тому, что вы её точно правильно к себе подключили и правильно используете.
И да, будете смеяться, но очень даже в ходу тесты, которые проверяют, какие запросы генерирует ORM, или хотя бы их количество. Потому что иначе вы не гарантируете, что ваш сервис соответствует требованиям, в этом случае нефункциональным. Особенно легко сломать что-то при изменении уже написанного.
Хотя на простых проектах, где нагрузки нет, и нет больших потерь денег из-за подобных ошибок, всё это в общем-то и не нужно.
Вот тут кажется пошла интересная мысль. Что если работа маппера проаеряется косвенно в более крупном тесте, то зачастую этого уже достаточно, чтобы проверить его работу.
В некотором смысле да, например если это rest-контроллер, то нужен тест на основе mockMvc, который проверит, какой именно json возвращает сервер. Вы может быть ожидаете, что это тестировать не нужно и там всё работает само и со 100% гарантией, но на практике это не так. Там стоит проверять например форматы даты-времени, или во что сериализуются какие-то нестандартные типы, типа BigDecimal
Вы так будете объяснять бизнесу, когда из-за бага в мапстракте баг будет уже у вас, и на проде будет инцидент? Сомневаюсь, что они оценят :)
Ну извините, что вам не понравилось, у меня вот такая)
Сейчас на бэке проекты пишут либо с Lombok, либо на Kotlin. Тот же spring поддерживает kotlin, не обламывается.
Они мне конечно ничем не обязаны. Но от этого более удобно мне не становится ни с какой стороны.