Всем привет!

Внимание, короткий пост-вопрос.
Кто для чего использует аспекты (AspectJ) в Java? И использует ли?) Если нет, то почему?
Я вижу одно "красивое" применение - реализация шаблона Декоратор, о котором я упоминал в https://t.me/javaKotlinDevOps/124
Самые очевидные примеры, чем можно "декорировать" метод - журналирование, мониторинг, аудит.
Напишите в комментах, плиз)

#java #aspects

Всем привет!

Я уже писал про библиотеку с улучшенными assert-ами - Truth https://t.me/javaKotlinDevOps/51
Вот пример вывода ошибки в лог для такой банальной вещи, как проверка результата функции на true.
"Ванильный" JUnit 5:

java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertTrue(Assert.java:53)

Понятно, что проверка не прошла, не понятно - где, пока не посмотришь код теста. Дело упрощается, если в методе один assertTrue, есть рекомендации так делать - один тест = одна проверка. Но это не всегда удобно. И в любом случае если код написан какое-то время назад - придется лезть в тест.

JUnit5 + Truth:

value of: needFilter(...)
expected to be true

Совсем другое дело!)))

#unittests

Всем привет!

Заметка из серии "хозяйке на заметку" про Docker.
При сборке docker образа мы можем передать в команду docker build контекст сборки.
Как правило во всех примерах это последний аргумент в виде точки. Т.е. текущего каталога.
Что это такое?
Это каталог в хостовой системе, из которого можно копировать данные в образ командами COPY в Dockerfile. Да, Dockerfile тоже должен лежать в контексте
Как его можно задать при сборке:
1) указав каталог
2) указав архив с нужными файлами
3) указав git репозиторий (!)
4) указать только Dockerfile как контекст, если копировать в образ ничего не надо
5) указать только Dockerfile как контекст, и с помощью команд RUN wget или RUN curl в нем выкачать данные для образа по http

Что важно - docker client при запуске сборки упаковывает все содержимое контекста и оправляет его docker daemon. Т.е. указывать корневую папку точно не стоит) Лучше создать новую папку и положить туда только необходимое. Альтернатива - использовать файл .dockerignore
Детали - https://docs.docker.com/engine/reference/commandline/build/

P.S Оффтопик - похоже создатели Docker вдохновлялись git-ом. docker push\pull\commit И упомянутый выше .dockerignore

#docker

Всем привет!

В протоколе HTTP, а также gRPC, основанном на HTTP/2, есть возможность передачи параметров запроса разными способами:
1) в заголовках
2) в параметрах
3) в path части url
4) в теле запроса

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

1) headers - не бизнесовые, технические данные. Примеры: id для tracing, для логирования, маршрутизации, токены\куки для авторизации. Ключевой момент - в бизнес-процессе эти данные не используются
2) params - как правило используются в GET запросах, по сути фильтр для выборки данных
3) path - как правило в REST запросе, построенном на концепции REST ресурсов, для идентификации ресурса: GET\PUT\DELETE .../order/{nnn}
4) body - атрибуты объекта для создания\обновления в REST. Любая закрытая информация - https шифрует заголовки и тело запроса, но само собой не шифрует параметры и путь. Большие объемы данных, в URL есть ограничения на длину, причем в разных браузерах и проксях они разные, лучше к ним не приближаться). По объему данных в заголовках также есть ограничения на веб-серверах, привет "413 Entity Too Large". Размер можно подкрутить в большую сторону, но опять же это не наш метод)

#rest #api

Всем привет!
При использовании JPA в проекте может возникнуть вопрос - нужно ли JPA Entity мапить на DTO, а точнее когда это нужно делать?
Вот хорошая статья с ответом на этот вопрос: https://thorben-janssen.com/object-mapper-dto/
#jpa #mappers

Всем привет!

При создании образа Docker нужно выбрать базовый образ - образ содержащий минимальный набор необходимых CLI утилит, сервисов, конфигураций и фреймворков необходимых для того, чтобы заработало ваше приложение. Какой минимальный размер этого образа?
Ответ - нулевой.
Есть специальное зафиксированное имя scratch - в DockerFile будет выглядеть как:
FROM scratch
https://docs.docker.com/build/building/base-images/#create-a-simple-parent-image-using-scratch
Но сразу скажу - там не будет даже shell - sh, bash. Вообще ничего.
Все необходимые утилиты нужно будет добавлять руками в процессе сборки образа.
Путь для сильных духом) Или случай каких-то очень специфичных образов.

Что же должно быть в образе для Java приложения:
1) JRE и все необходимое для того, чтобы она запустилась)
Далее все зависит от необходимости в отладке внутри образа. По моему опыту она нужна, а значит нужны:
2) Linux shell
3) CLI утилиты для работы с файловой системой
4) curl\wget - для проверки маршрутизации в k8s
5) CLI редактор - vi, nano - для правки конфигов "на ходу"
6) возможно ssh сервер
7) возможно утилиты из состава JDK

Минималистичные образы можно поискать по словам busybox и alpine.
Размер - до 5 Мб(!) Само собой они без Java. Но есть основанные на них образы с Java размером порядка 55 Мб с JRE (Linux Temurin Java 11). Для сравнения обычные образы c JRE - 85-150 Мб. С JDK размер можно умножать на 3.
Что важно - в Linux куча настроек, поэтому важно выбрать проверенный и оптимизированный для работы с Java базовый образ.

P.S. Точно не стоит использовать образы с полноценным Linux - Debian, Ubuntu... Размер будет порядка 500+ Мб, а пользы - ноль.

P.P.S. Еще нужно помнить, что активное использование Spring Framework легко добавляет в размер образа ~ 100 Мб)

#docker

Всем привет!

Чем хорош Spring Framework?
1) Inverse of Control и Dependency Injection
2) Очень много модулей-адаптеров к различным технологиям: Data, Data Kafka, Web MVC, WebFlux, Security, Statemachine, Cloud ... с упрощенным и насколько это возможно единообразным API.
Но это не все.
Но Spring приходит на помощь и там, где его не особо ждали) Хочу рассказать о менее известном, но полезном функционале Spring:
1) Расширенный маппинг Enum при передаче значений через REST API: https://www.baeldung.com/spring-boot-enum-mapping
2) Улучшение логирования при падении Spring Boot при старте - все эти bean not found exception: https://www.baeldung.com/spring-boot-failure-analyzer
3) Централизованная обработка ошибок: https://www.baeldung.com/exception-handling-for-rest-with-spring

#spring #spring_boot

Всем привет!

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

Задавались ли вы вопросом: какие типы данных использовать в Java API - примитивные или типы-обвертки (boxed)?

Однонозначного ответа как водится нет, но есть ряд правил.

Плюсы примитивных типов:
1) занимают меньше памяти, т.к нет накладных расходов на Java объекты. Какой величины эти расходы - можно почитать тут: https://www.baeldung.com/jvm-measuring-object-sizes или посмотреть с шутками и прибаутками и хорошей дозой хардкора тут https://www.youtube.com/watch?v=3BmznLJAgaA

Плюсы обверток:
1) могут использоваться в generic-ах. А generic-и лежат в основе всяких разных фреймворков. Если вы не уверены, что не используете такие - то вот примеры: Mockito, Truth и AssertJ (см. https://t.me/javaKotlinDevOps/51), Hibernate
2) могут использоваться для передачи null значений. Да, не всегда это правильно, чаще неправильно, но такие кейсы бывают.

И если исходя из сказанного выше возникает мысль - может ну ее, эту производительность, пусть будет универсальный готовый к будущим изменениям код, то вот еще два фактора:

1) если в процессе написания кода потребуется boxing из примитивного типа в обвертку и наоборот, то в этих строчках кода могут возникать необъяснимые NPE. Особенно "хороши" такие NPE до Java 14)))
Примеры:
а)
Boolean variable;
if (variable) {
}
б)
Integer boxed;
int i = boxed;

Т.е. имеет смысл посмотреть на чужие API, которые мы используем и прикинуть, как часто придется преобразовывать типы.

2) код в настоящее стал достаточно гибким. В том плане, что если 50 лет назад для отладки программы нужно было набить код на перфокарте и дождаться своей очереди для ее исполнения на сервере, а 30 лет назад исправить большую Asm или C программу было тем еще приключением, то сейчас при правильном разбиении на микросервисы, использовании практик чистого кода и главное написании модульных тестов отрефакторить код не сложно. Если у вас не так - предлагаю над этим задуматься)

Итого:
1) Если нужны generic-и и\или придется часто преобразовывать в boxed типы - имеет смысл использовать их везде в своем API.
2) Если важна производительность - примитивы там, где большие объемы данных.
3) В остальных случаях предлагаю присмотреться к примитивам.
Если концепция поменялась - всегда есть рефакторинг. Чуть сложнее с Java API, выставленным наружу - выпущенным в виде библиотеки. Тут нас спасет версионирование API.

#java #types

Всем привет!

Выпил бокал пива и захотелось немного пофилософствовать)
У меня часть просят готовое решение какой-то проблемы. Это может быть способ интеграции, выбор места для хранения данных, языка программирования, способ разбиения проекта на микросервисы и модули, как сделать правильное API...
Что на это хочется сказать.
1) иметь каталог готовых решений - это круто. Именно он оправдывает существование архитекторов и техлидов в команде. Использование паттернов, #patterns - это как раз про это, про переиспользование знаний. И я над таким каталогом работаю)
2) вместе с тем приходится признать, что далеко не всегда есть готовые и главное наиболее подходящие к конкретной ситуации решения.
Хорошо если бы всегда было так: "Как нам сделать ххх?". Думаешь 10 минут. "Делайте так и так, а так не делайте". Всё понятно, все счастливы, приложение легко и безболезненно попадает на ПРОД. Мечты, мечты)

По факту самый лучший способ принять оптимальное решение по проекту - это понимать все возможные варианты и выбрать из них наиболее подходящий исходя из:
а) команды
б) компании
в) проекта
г) сроков
д) чего-то еще что я забыл)
И лучше всего, по принципам Agile, если понимая все возможные варианты, их плюсы и минусы, решение будет принимать команда. Почему лучше? Потому что решение, полученное извне, IMHO будет "чужеродным". Причины его принятия могут со временем потеряться.
Сторонний архитектор может банально не знать особенностей команды, как устроена кодовая база и т.д.

В этом плане само название должности - архитектор - неверное. "Каменную" архитектуру сложно отрефакторить. Программную при правильном подходе к разработке - легко. Если бы все дома вокруг строились по индивидуальным проектам - это банально было бы очень дорого. С ПО - это суровая правда жизни.

Вывод: надо изучать паттерны и существующие решения. После любого проекта нужна "ретроспектива" - индивидуальная или общекомандная, на которой стоит отметить что "выстрелило", а что лучше в будущем не использовать. Ну и конечно учиться, учиться и учиться...)))

#arch #arch_compromises

Всем привет!

Не знаю зарегистрировались ли вы на бесплатный день JPoint, но мне понравился там доклад "Пирамида потребностей Маслоу для Java/Kotlin-разработчика" https://jpoint.ru/talks/dfb53bfc4ec74165830e81c036a28ad8
Доклад был вчера, регистрация закрыта, увы, но можно скачать pdf.

Мне понравились две вещи:

1) идея разделения всех инструментов разработчика на уровни по их необходимости. Как это сделано в докладе - можно поспорить, но сама идея хороша.

2) нашел новые для себя инструменты - генератор тестов для бизнес-логики, расшаривание набора зависимостей между проектами в Gradle, автоматизация обновления библиотек в проекте. Еще интересна метрика Hits of code вместо Lines of code, полезно для для наблюдения за проектом. Жаль, что SonarQube ее не умеет считать.

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

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

#conference #tools

Всем привет!

Уже писал про Kotlin DSL как одно из преимуществ языка: https://t.me/javaKotlinDevOps/38
А как насчет примеров? Легко)
Где же используется Kotlin DSL?
1) В Spring для динамических конфигураций: Spring https://spring.io/blog/2023/03/16/kotlin-dsls-in-the-world-of-springdom
2) В Gradle как скрипт сборки вместо Groovy: https://docs.gradle.org/current/userguide/kotlin_dsl.html
3) TeamCity (конечно же!) для скриптов CI\CD - https://www.jetbrains.com/help/teamcity/kotlin-dsl.html#Editing+Kotlin+DSL

В статье про Spring также говорится о фичах Kotlin, которые позволяют использовать его как DSL.
А подробнее эта тема раскрыта тут: https://www.jmix.ru/cuba-blog/kotlin-dsl-from-theory-to-practice/

И на сладкое пример как пошагово сделать свой DSL на Kotlin: https://www.baeldung.com/kotlin/dsl

#kotlin #kotlin_dsl #dsl

Всем привет!

В развитие темы про готовые решения и переиспользование знаний хочу поговорить про переиспользование кода.
Ясно, что все разработчики переиспользуют готовые решения - Spring Framework, Apache Commons да и вообще любые подключаемые к проекту библиотеки.
Стоит ли добавлять еще одну?
Ответ как всегда неоднозначен.

Во-первых - чего не должно быть в общем (common) коде.
1) не должно быть доменных объектов. Почему? Потому что по большому счету домен у каждого свой. Приведу пример с банком. Наверное у половины команды разработки в банке в домене есть карта. Только это всегда разная карта. У кого-то это номер+ФИО+дата. А кого-то объект с н-цатью атрибутами: тип, платежная система, валюта, лимиты, персональный менеджер, офис выдачи, признак дополнительной, дизайн карты....
Первой команде не нужны атрибуты второй, второй не хватит слишком простого интерфейса первой.
Что касается доменной логики: если она общая у нескольких команд - вполне можно и нужно вынести ее в общий код в отдельный модуль, особое внимание обратив на версионирование.
2) не должно быть элементарного кода. Объяснять думаю не нужно.
3) не имеет смысла выносить в common код временные костыли, которые будут неактуальны через полгода.
4) не должно быть узкоспециализированного кода. Все же отдельная библиотека - это накладные расходы из-за отдельного CI стека: git, джоба сборки, проверка качества кода, хранилище артифактов.

Второе важное условие применимости common кода: наличие maintainers. Т.е. разработчиков, которые понимают как должен выглядеть общий код и что немаловажно - готовы тратить силы на его поддержку. Важны оба фактора. Первый - вспомним Spring: у него много модулей, но изучив Spring Core и какой-то из модулей - подключать другие становится достаточно просто. Фактор наличия времени важен т.к. очень мало алгоритмов, интеграций остаются неизменными. Часто попытка применить общий код в новом сервисе приводит к тому, что выявляется новый use case и требуется доработка.

Если же все условия выполняются и вы решили создать общие библиотеки - нужно помнить о следующих важных факторах.

1) должна быть документация с примерами использования. Модульные тесты вполне подойдут на эту роль, см https://t.me/javaKotlinDevOps/33. Еще вариант - эталонный проект, который должен собираться!) Иначе проще будет написать свой код чем разбираться в чужом.

2) процесс подключения общего кода в новый проект должен быть максимально простым, в идеале - через генератор каркаса а-ля https://start.spring.io/

3) нужно правильно выбрать модульность. Как пример можно привести Spring или семейство библиотек Apache Commons. Должна быть возможность подключать отдельные модули к проекту, для их группировки, если она нужна, можно использовать Spring starters.

4) должна быть описанная политика версионирования и API deprecation.

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

#common_code

Всем привет!

Один из не побоюсь этого слова трендов последнего времени - ChatGPT.
Статьи, доклады на конференциях. В т.ч. и по разработке.
Кто-нибудь пробовал уже? Для каких задач? Как оно?)

Сейчас баги уже не те)

Всем привет!

Возвращаясь к теме Machine Learning. Если погуглить эту тему, то в первых сторонах будет Python и библиотеки на Python. Почему не Java - вот тут попытка дать ответ: https://habr.com/ru/companies/piter/articles/429596/ Согласен с тем, что для такой большой экосистемы как Java возможностей для ML должно быть больше. Микросервисы конечно рулят, мультиплатформенность, все такое, но Java разработчиков много и по ML задач будет также очень много.

Как ложку меда хочу отметить, что какие-то ML библиотеки для Java все же есть https://onix-systems.com/blog/top-10-java-machine-learning-tools-and-libraries. И NLP до кучи https://www.baeldung.com/java-nlp-libraries NLP на всякий случай - это natural language processing)))

#ml #nlp #libraries

Всем привет!

Хочу продолжить серию постов про #microservices
Я уже писал про их плюсы и минусы. Одним из главных минусов является увеличенная сложность развертывания и поддержки, а также накладные расходы на сетевое взаимодействие. Как ответ на эту сложность может возникнуть идея - а давайте сделаем несколько независимых модулей в одном микросервисе, а потом при необходимости их разделим. Ключевое слово здесь - независимый. Идея на самом деле здравая. "Модулем" здесь может быть модуль Maven\Gradle или даже пакет. Но есть одна проблема: если не следить за связями между "модулями" - они со временем становятся связанными и получается тот самый спагетти код))) А тогда выделение нового микросервиса превратится в распутывание клубка зависимостей. Значит нужна проверка границ "модулей". Лучший способ сделать надежную постоянно выполняемую проверку - это написать unit тест. И запускать его на prcheck и сборке конечно же. Но любой тест должен быть антихрупким - т.е. при изменениях в коде оставаться актуальным. В нашем случае - в случае добавлении\изменении\удалении "модулей" в проекте.
К чему я веду: есть технология, решающая эту проблему - Spring Modulith https://spring.io/projects/spring-modulith
А вот статья, описывающая предпосылки его появления более подробно и способ его использования: https://habr.com/ru/articles/701984/
Мне нравится.
Зависимость от Spring на мой взгляд не является большим минусом. Требование объявить все пакеты в одном модулей Maven\Gradle - минус чуть пожирнее, но на мой взгляд тоже не критично. И сборка в этом случае будет быстрее.

#spring #microservices

Всем привет!

Во-первых поздравляю всех с Днем Победы!

Но совсем без разработки в посте я не могу)
Поэтому вернемся к разговору про API.
Давно хотел написать про важность идемпотентности API, о которой упоминал в https://t.me/javaKotlinDevOps/24
Но меня опередили https://habr.com/ru/companies/yandex/articles/442762/
Причем добавить по большому счету нечего, кроме пары замечаний.
Первое - лучше не пытаться решить проблему повторных заказов и таймаутов на клиентской стороне.
Основные проверки должны быть на сервере, на клиенте - дополнительные, улучшающие клиентский опыт.
Ну и второй момент - правильность реализации идемпотентности невозможно проверить автоматически, достаточно сложно - автотестами. Очень важен процесс код-ревью.

#api

Всем привет!

Сегодня хотел бы поговорить про код-ревью.
Для начала - что оно нам дает?

1) единообразие кодовой базы. Люди приходят и уходят, а код остается) Новичок в команде должен во-первых быстро разобраться в проекте, а во-вторых - писать код в едином стиле. Я говорю не только про код-стайл, но и про наименования, разделение по модулям и слоям, переиспользование кода и многое другое
2) понятный, "чистый" код в проекте. Тут можно снова сказать про важность быстрого вхождения в проект новых людей. Важная ремарка - чтобы код был простым и понятным ревьювер должен сознательно ставить себе такую цель.
3) общее владение кодом в команде. Если код посмотрел ревьювер и сделал это качественно, а не формально - этот код теперь знают два человека. Легче вносить какие-то правки, проводить рефакторинг.
4) альтернативный взгляд на решение задачи. Не всегда предложенное решение будет правильным, и нужно все переделывать. Но узнать о других вариантах и обсудить к примеру будущий рефакторинг точно будет полезно. Отдельно хочется отменить, что иногда лучше прорабатывать решение до написания кода, чтобы избежать потерь времени на код-ревью и переделывание. Примеры: новичок в коданде или просто сложная задача.
5) обмен знаниями о проекте, библиотеках, утилитах и даже языке программирования. Причем узнать что-то новое может и автор кода, и ревьювер.
6) повторяющиеся ошибки\"холиварные" вопросы на код-ревью должны обсуждаться и фиксироваться. И т.об. они являются источником для новых правил в статическом анализаторе кода и в правилах работы над проектом

И как следствие вышесказанного получаем повышение качества кода.

P.S. Далее расскажу про рекомендации для автора и ревьювера, а также про кросс-командное ревью.

#code_review

Всем привет!

Продолжаю тему code review, поговорим про рекомендации ревьюверам.

1) работа с PR - это как правило текстовая коммуникация: Bitbucket, Gitlab, ... При таком общении теряется часть информации - тон, эмоциональная окраска... Следовательно, фразу которая по замыслу была нейтральной, рекомендацией, можно воспринять неправильно, далее перейти на личности и в результате затянуть ревью на дни, недели... Отсюда первая рекомендация: если это внутрикомандное ревью и команда рядом - попробуйте провести ревью личности

2) избегайте повелительного наклонения в замечаниях к PR, типа сделай это, исправь это. В личном общении мы обычно так не говорим, не нужно это делать и в Pull Request (PR, также известен как Merge Request). Лучше использовать фразы типа "предлагаю", "как насчет", "я считаю, что лучше" и т.д.

3) если замечание сложное - лучше созвониться и проговорить его, чтобы не было недопонимания

4) если замечаний много - лучше выдавать их "волнами", от высокоуровневых к простым. Высокоуровневые - это выбранный алгоритм, неправильное разделение на слои и модули, явные ошибки в бизнес-логике. Простые - опечатки, наименования... Почему так - если автор получает PR с 30 замечаниями, это обескураживает, т.к. во-первых не понятно с чего начинать править, а во-вторых - автор может посчитать, что его просто "гасят". Да, мы люди, нужно иметь это в виду. Кроме того, может возникнуть ситуация, когда после высокоуровневых правок какие-то замечания станут неактуальны. Также такая тактика снижает вероятность ситуации, когда из 30 замечаний при исправлении можно что-то потерять

5) Хорошей практикой будет предложение примера кода, который исправит замечания. Так мы убираем проблемы интерпретации текста и сокращаем время ревью. Также можно дать ссылку какой-то авторитетный источник, например на правила разработки в команде, которых напишу далее.

6) не всегда стоит ждать исправления 100% замечаний. Почему? Главная причина - есть такая штука как Lead Time, скорость вывода фичей важна. Как же с качеством кода? Когда я говорю о том, что какие-то проблемы можно в данном PR пропустить - я говорю о тривиальных замечаниях. Т.е. был код на троечку, стал на четверку - это уже хорошо. Если к следующим PR автор сделает его изначально на четверку - значит мы все сделали правильно. Если по прежнему на тройку - тут проблема не в code review(
Как по мне нормально - 1-5 итераций ревью.

7) реагировать на PR надо быстро, максимум в течение суток, лучше раньше. Это касается ревьюверов, чей апрув обязателен для вливания PR. Если глянуть не получается - нужно дать об этом знать автору, чтобы у него была возможность попросить посмотреть PR кого-то еще. Если команда большая - для этих целей хорошо подходит отдельный чатик. Да, вы как ревьювер часто заняты другими, возможно более важными задачами. Но просто игнорировать - неправильно. Основные проблемы здесь - потеря автором фокуса на задаче, возможная блокировка выполнения следующих задач и потеря мотивации писать код быстро. Почему я говорю про возможную блокировку - есть люди, у которых лучше получается в многозадачность. Они могут взяться за следующую задачу не дожидаясь вливания текущей, а потом быстро все смержить и влить. Но, как говорится, это не только лишь все) Еще один потенциальный бонус - если вы как ревьювер хорошо выполняете свою задачу, то с большим правом можете требовать что-то от автора. Например - разбивать задачу на небольшие PR, о чем пойдет речь дальше

8) Ревью кода - не менее сложная задача, чем его написание. Я бы даже сказал более сложная. А чем больше кода - тем сложнее в него вникнуть. Поэтому лучше договориться на берегу о размерах PR в команде и строго требовать соблюдения этого правила. Если договоренностей не было - один раз стоит "помучаться", потом поговорить с автором, но начиная со 2-го отклонять такие PR. Иначе есть риск, что большая часть правок будет пролистана, ведь часто даже не понятно, где ключевые изменения. А в этом случае теряется смысл ревью кода. Еще альтернатива - спросить у автора куда смотреть в первую очередь. Но это все костыли, лучше придерживаться правила по размеру. Я бы его ограничил в 100 строк кода.

9) Я надеюсь, что у вас подключен автоматический prcheck - проверка PR. Если это так - не нужно комментировать то, что уже прокомментировал бот SonarQube. О том, какие замечания SonarQube правим также нужно договорится на берегу и включить в Quality Gate.
Да, о настройках DevOps для код ревью сделаю отдельный пост.

10) Типовые ошибки на код-ревью лучше проговорить со всей командой и вынести в отдельный документ или в SonarQube. Это сэкономит время в будущем.

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

12) Нужно строго соблюдать scope задачи. Как бы ни хотелось поправить еще один, найденный на код-ревью баг - нельзя, это затягивает процесс. Начали с исправления бага, а закончили архитектурным рефакторингом всего сервиса - да, возможно, но не в рамках одного PR) А у нас есть Lead Time и бэклог

13) Если ревью зашло в тупик - подключайте вашего техлида, тимлида, любого авторитетного разработчика. Возможно нужен взгляд со стороны.

14) В абсолютном большинстве PR в целом код хороший. Если это не так - стоит подумать там ли вы работаете) Если вы видите крутое решение - стоит это отметить отдельным комментарием. Если просто хороший код, но с замечаниями - в первом замечании стоит отметить, что "в целом все хорошо, но..."

15) если в PR несколько однотипных ошибок, не стоит оставлять замечания на всех. Это захламляет PR. Лучше отменить одну, максимум две. А далее можно посмотреть - найдет ли автор остальные)

#code_review