Так и есть. Поэтому, на мой взгляд, ставка должна быть не "помнить", а на инструменты, которые напомнят сами: метрики на deprecated-эндпоинты, алерты на размер ответа/heap, lint на отсутствие LIMIT в запросах. Память - плохой бэкап для tech-debt, особенно в команде
Полностью согласен, это ,по-моему, главная мысль из всей истории. TODO это приватная заметка для того, кто открыл файл; тикет это публичное обязательство команды. Они решают разные задачи и не заменяют друг друга
Я бы ещё добавил третий уровень - runtime-видимость: метрика/алерт на сам артефакт (вызовы deprecated-эндпоинта, размер ответа, время выполнения и тд и тд. Тикет говорит "мы знаем, что это надо починить", метрика говорит "вот сейчас оно начинает болеть". Без третьего уровня тикет может так же тихо висеть в бэклоге, как TODO в коде
Разделение tech-debt на "задокументированный в коде"
Раньше я сам оч любил Хибер)) Но чем глубже его изучаешь, чем больше сталкиваешься со всякими нюансами в проде, тем яснее, что это довольно сложный инструмент. Ошибиться или допустить незаметный для разработки кейс, который вылезет в рантайме оч легко Поэтому у нас на платформенном уровне сейчас есть рекомендация по возможности уходить в сторону Spring Data JDBC или jooq, где меньше магии и больше контроля over sql)
Тесты и так и так будут одинаковыми, ведь нужно протестировать всю логику маппинга) огромное преимущество - это null safe библиотека, как минимум все эти кейсы проверять не нужно
Про сбой - спорно, но окэй, такое бывает, нужно смотреть что генерируется.
В статье есть пример про вынос некоторой логики в отдельные классы, так же можно выносить общие маппинги в отдельные интерфейсы и тоже их использовать. Это очень удобно.
В IntelliJ idea есть шикарный плагин для map struct’a , который подсвечивает и видит весь синтаксис, даже в строках в expression
На самом деле map struct далеко не идеален, есть сложные вещи, например прикидывание в контексте нескольких параметров, но в статье про подводные камни не сказано(
Некоторые пакеты можно исключать из покрытия, что является классной практикой. У нас, например, сущности и мапперы исключены из подсчета покрытия. Это можно гибко настраивать в JacoCo или сонаре.
Спасибо ко комментарий! Из вашего кода в примере видятся лишние if'ы
//Первый, который всегда будет false
if(values.isEmpty()) {
return
}
//Второй, который всегда будет false
if(firstElement == null) {
return;
}
Остальные альтернативные сценарии возможны. Их нужно тестировать отдельно: мокать вызов клиента и выкидывать ошибку. Имеется ввиду сценарии orElseThrow . Почему jacoco считает их покрытыми - большой вопрос :)
И конечно, еще нужен альтернативный сценарий, когда метод eventService.sendEvent не вызовется по бизнес логике. Данные сценарии я специально не отражал в туториале, он и так получился довольно большой(
Вы правы на счет того, что jacoco не отслеживает покрытие ветки .ifPresent(eventService::sendEvent). По идее, здесь по бранчам покрыто 50%, хотя при генерации отчета index.html отображается 100%
Согласен. У TODO нет дедлайна и владельца - поэтому он и тухнет. Тикет в бэклоге хотя бы попадает в обсуждение на груминге, и его кто-то да заденет
Так и есть. Поэтому, на мой взгляд, ставка должна быть не "помнить", а на инструменты, которые напомнят сами: метрики на deprecated-эндпоинты, алерты на размер ответа/heap, lint на отсутствие LIMIT в запросах. Память - плохой бэкап для tech-debt, особенно в команде
Полностью согласен, это ,по-моему, главная мысль из всей истории. TODO это приватная заметка для того, кто открыл файл; тикет это публичное обязательство команды. Они решают разные задачи и не заменяют друг друга
Я бы ещё добавил третий уровень - runtime-видимость: метрика/алерт на сам артефакт (вызовы deprecated-эндпоинта, размер ответа, время выполнения и тд и тд. Тикет говорит "мы знаем, что это надо починить", метрика говорит "вот сейчас оно начинает болеть". Без третьего уровня тикет может так же тихо висеть в бэклоге, как TODO в коде
Ты это как предлагаешь отслеживать в динамике?
:D
Раньше я сам оч любил Хибер)) Но чем глубже его изучаешь, чем больше сталкиваешься со всякими нюансами в проде, тем яснее, что это довольно сложный инструмент. Ошибиться или допустить незаметный для разработки кейс, который вылезет в рантайме оч легко
Поэтому у нас на платформенном уровне сейчас есть рекомендация по возможности уходить в сторону Spring Data JDBC или jooq, где меньше магии и больше контроля over sql)
Тесты и так и так будут одинаковыми, ведь нужно протестировать всю логику маппинга) огромное преимущество - это null safe библиотека, как минимум все эти кейсы проверять не нужно
Про сбой - спорно, но окэй, такое бывает, нужно смотреть что генерируется.
В статье есть пример про вынос некоторой логики в отдельные классы, так же можно выносить общие маппинги в отдельные интерфейсы и тоже их использовать. Это очень удобно.
В IntelliJ idea есть шикарный плагин для map struct’a , который подсвечивает и видит весь синтаксис, даже в строках в expression
На самом деле map struct далеко не идеален, есть сложные вещи, например прикидывание в контексте нескольких параметров, но в статье про подводные камни не сказано(
Некоторые пакеты можно исключать из покрытия, что является классной практикой. У нас, например, сущности и мапперы исключены из подсчета покрытия. Это можно гибко настраивать в JacoCo или сонаре.
Спасибо ко комментарий! Из вашего кода в примере видятся лишние if'ы
Остальные альтернативные сценарии возможны. Их нужно тестировать отдельно: мокать вызов клиента и выкидывать ошибку. Имеется ввиду сценарии
orElseThrow. Почему jacoco считает их покрытыми - большой вопрос :)И конечно, еще нужен альтернативный сценарий, когда метод
eventService.sendEventне вызовется по бизнес логике. Данные сценарии я специально не отражал в туториале, он и так получился довольно большой(Вы правы на счет того, что
jacocoне отслеживает покрытие ветки.ifPresent(eventService::sendEvent). По идее, здесь по бранчам покрыто50%, хотя при генерации отчетаindex.htmlотображается100%