Всем привет!
При создании образа 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
При создании образа 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
Docker Documentation
Base images
Learn about base images and how they're created
Всем привет!
Чем хорош 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
Чем хорош 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
Baeldung
Enum Mapping in Spring Boot | Baeldung
Explore different ways to implement case-insensitive enum mapping in 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
Возвращаюсь с постами из вынужденного перерыва, связанного как обычно бывает с работой)
Задавались ли вы вопросом: какие типы данных использовать в 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
Baeldung
Measuring Object Sizes in the JVM | Baeldung
Learn how to measure Java object sizes with various tools such as JOL, Java Agents, and the jcmd command-line utility
Всем привет!
Выпил бокал пива и захотелось немного пофилософствовать)
У меня часть просят готовое решение какой-то проблемы. Это может быть способ интеграции, выбор места для хранения данных, языка программирования, способ разбиения проекта на микросервисы и модули, как сделать правильное API...
Что на это хочется сказать.
1) иметь каталог готовых решений - это круто. Именно он оправдывает существование архитекторов и техлидов в команде. Использование паттернов, #patterns - это как раз про это, про переиспользование знаний. И я над таким каталогом работаю)
2) вместе с тем приходится признать, что далеко не всегда есть готовые и главное наиболее подходящие к конкретной ситуации решения.
Хорошо если бы всегда было так: "Как нам сделать ххх?". Думаешь 10 минут. "Делайте так и так, а так не делайте". Всё понятно, все счастливы, приложение легко и безболезненно попадает на ПРОД. Мечты, мечты)
По факту самый лучший способ принять оптимальное решение по проекту - это понимать все возможные варианты и выбрать из них наиболее подходящий исходя из:
а) команды
б) компании
в) проекта
г) сроков
д) чего-то еще что я забыл)
И лучше всего, по принципам Agile, если понимая все возможные варианты, их плюсы и минусы, решение будет принимать команда. Почему лучше? Потому что решение, полученное извне, IMHO будет "чужеродным". Причины его принятия могут со временем потеряться.
Сторонний архитектор может банально не знать особенностей команды, как устроена кодовая база и т.д.
В этом плане само название должности - архитектор - неверное. "Каменную" архитектуру сложно отрефакторить. Программную при правильном подходе к разработке - легко. Если бы все дома вокруг строились по индивидуальным проектам - это банально было бы очень дорого. С ПО - это суровая правда жизни.
Вывод: надо изучать паттерны и существующие решения. После любого проекта нужна "ретроспектива" - индивидуальная или общекомандная, на которой стоит отметить что "выстрелило", а что лучше в будущем не использовать. Ну и конечно учиться, учиться и учиться...)))
#arch #arch_compromises
Выпил бокал пива и захотелось немного пофилософствовать)
У меня часть просят готовое решение какой-то проблемы. Это может быть способ интеграции, выбор места для хранения данных, языка программирования, способ разбиения проекта на микросервисы и модули, как сделать правильное 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
Не знаю зарегистрировались ли вы на бесплатный день JPoint, но мне понравился там доклад "Пирамида потребностей Маслоу для Java/Kotlin-разработчика" https://jpoint.ru/talks/dfb53bfc4ec74165830e81c036a28ad8
Доклад был вчера, регистрация закрыта, увы, но можно скачать pdf.
Мне понравились две вещи:
1) идея разделения всех инструментов разработчика на уровни по их необходимости. Как это сделано в докладе - можно поспорить, но сама идея хороша.
2) нашел новые для себя инструменты - генератор тестов для бизнес-логики, расшаривание набора зависимостей между проектами в Gradle, автоматизация обновления библиотек в проекте. Еще интересна метрика Hits of code вместо Lines of code, полезно для для наблюдения за проектом. Жаль, что SonarQube ее не умеет считать.
Ну и интересно кто оказался на вершине пирамиды...
В общем рекомендую почитать, возможно найдете для себя что-то новое.
#conference #tools
JPoint 2023. Конференция для опытных Java‑разработчиков
Пирамида потребностей Маслоу для Java/Kotlin-разработчика | Доклад на JPoint 2023
Спикеры постараются раскрыть тему необходимых каждому Java/Kotlin-разработчику dev 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
Уже писал про 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
Telegram
(java || kotlin) && devOps
Всем привет!
Практически не писал про Kotlin, хотя он есть в названии канала. Надо исправляться.
Первый вопрос, который возникает при упоминании Kotlin - зачем он нужен, есть же Java?
Отвечаю:
1) Null safety - на уровне объявления типа мы говорим, допускает…
Практически не писал про Kotlin, хотя он есть в названии канала. Надо исправляться.
Первый вопрос, который возникает при упоминании Kotlin - зачем он нужен, есть же Java?
Отвечаю:
1) Null safety - на уровне объявления типа мы говорим, допускает…
Всем привет!
В развитие темы про готовые решения и переиспользование знаний хочу поговорить про переиспользование кода.
Ясно, что все разработчики переиспользуют готовые решения - 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
В развитие темы про готовые решения и переиспользование знаний хочу поговорить про переиспользование кода.
Ясно, что все разработчики переиспользуют готовые решения - 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
Telegram
(java || kotlin) && devOps
Всем привет!
Каким должен быть хороший тест?
Я в первую очередь про модульные (unit), но в принципе правила применимы к любым.
Основные моменты:
1) правило Arrange, Act, Assert https://xp123.com/articles/3a-arrange-act-assert/
Тест делится на три части:…
Каким должен быть хороший тест?
Я в первую очередь про модульные (unit), но в принципе правила применимы к любым.
Основные моменты:
1) правило Arrange, Act, Assert https://xp123.com/articles/3a-arrange-act-assert/
Тест делится на три части:…
Всем привет!
Один из не побоюсь этого слова трендов последнего времени - ChatGPT.
Статьи, доклады на конференциях. В т.ч. и по разработке.
Кто-нибудь пробовал уже? Для каких задач? Как оно?)
Один из не побоюсь этого слова трендов последнего времени - 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
Возвращаясь к теме 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
Хабр
Что требуется сделать в языке Java для полноценной поддержки машинного обучения
Здравствуйте, коллеги! Из последних известий по нашим планируемым новинкам из области ML/DL: Нишант Шакла, " Машинное обучение с Tensorflow " — книга в верстке, ожидается в магазинах в январе Делип...
Всем привет!
Хочу продолжить серию постов про #microservices
Я уже писал про их плюсы и минусы. Одним из главных минусов является увеличенная сложность развертывания и поддержки, а также накладные расходы на сетевое взаимодействие. Как ответ на эту сложность может возникнуть идея - а давайте сделаем несколько независимых модулей в одном микросервисе, а потом при необходимости их разделим. Ключевое слово здесь - независимый. Идея на самом деле здравая. "Модулем" здесь может быть модуль Maven\Gradle или даже пакет. Но есть одна проблема: если не следить за связями между "модулями" - они со временем становятся связанными и получается тот самый спагетти код))) А тогда выделение нового микросервиса превратится в распутывание клубка зависимостей. Значит нужна проверка границ "модулей". Лучший способ сделать надежную постоянно выполняемую проверку - это написать unit тест. И запускать его на prcheck и сборке конечно же. Но любой тест должен быть антихрупким - т.е. при изменениях в коде оставаться актуальным. В нашем случае - в случае добавлении\изменении\удалении "модулей" в проекте.
К чему я веду: есть технология, решающая эту проблему - Spring Modulith https://spring.io/projects/spring-modulith
А вот статья, описывающая предпосылки его появления более подробно и способ его использования: https://habr.com/ru/articles/701984/
Мне нравится.
Зависимость от Spring на мой взгляд не является большим минусом. Требование объявить все пакеты в одном модулей Maven\Gradle - минус чуть пожирнее, но на мой взгляд тоже не критично. И сборка в этом случае будет быстрее.
#spring #microservices
Хочу продолжить серию постов про #microservices
Я уже писал про их плюсы и минусы. Одним из главных минусов является увеличенная сложность развертывания и поддержки, а также накладные расходы на сетевое взаимодействие. Как ответ на эту сложность может возникнуть идея - а давайте сделаем несколько независимых модулей в одном микросервисе, а потом при необходимости их разделим. Ключевое слово здесь - независимый. Идея на самом деле здравая. "Модулем" здесь может быть модуль Maven\Gradle или даже пакет. Но есть одна проблема: если не следить за связями между "модулями" - они со временем становятся связанными и получается тот самый спагетти код))) А тогда выделение нового микросервиса превратится в распутывание клубка зависимостей. Значит нужна проверка границ "модулей". Лучший способ сделать надежную постоянно выполняемую проверку - это написать unit тест. И запускать его на prcheck и сборке конечно же. Но любой тест должен быть антихрупким - т.е. при изменениях в коде оставаться актуальным. В нашем случае - в случае добавлении\изменении\удалении "модулей" в проекте.
К чему я веду: есть технология, решающая эту проблему - Spring Modulith https://spring.io/projects/spring-modulith
А вот статья, описывающая предпосылки его появления более подробно и способ его использования: https://habr.com/ru/articles/701984/
Мне нравится.
Зависимость от Spring на мой взгляд не является большим минусом. Требование объявить все пакеты в одном модулей Maven\Gradle - минус чуть пожирнее, но на мой взгляд тоже не критично. И сборка в этом случае будет быстрее.
#spring #microservices
Spring Modulith
Level up your Java code and explore what Spring can do for you.
Всем привет!
Во-первых поздравляю всех с Днем Победы!
Но совсем без разработки в посте я не могу)
Поэтому вернемся к разговору про API.
Давно хотел написать про важность идемпотентности API, о которой упоминал в https://t.me/javaKotlinDevOps/24
Но меня опередили https://habr.com/ru/companies/yandex/articles/442762/
Причем добавить по большому счету нечего, кроме пары замечаний.
Первое - лучше не пытаться решить проблему повторных заказов и таймаутов на клиентской стороне.
Основные проверки должны быть на сервере, на клиенте - дополнительные, улучшающие клиентский опыт.
Ну и второй момент - правильность реализации идемпотентности невозможно проверить автоматически, достаточно сложно - автотестами. Очень важен процесс код-ревью.
#api
Во-первых поздравляю всех с Днем Победы!
Но совсем без разработки в посте я не могу)
Поэтому вернемся к разговору про API.
Давно хотел написать про важность идемпотентности API, о которой упоминал в https://t.me/javaKotlinDevOps/24
Но меня опередили https://habr.com/ru/companies/yandex/articles/442762/
Причем добавить по большому счету нечего, кроме пары замечаний.
Первое - лучше не пытаться решить проблему повторных заказов и таймаутов на клиентской стороне.
Основные проверки должны быть на сервере, на клиенте - дополнительные, улучшающие клиентский опыт.
Ну и второй момент - правильность реализации идемпотентности невозможно проверить автоматически, достаточно сложно - автотестами. Очень важен процесс код-ревью.
#api
Telegram
(java || kotlin) && devOps
Всем привет!
Современная разработка - это микросервисы, микросервисы - это много внешних взаимодействий, а внешние взаимодействия - это API.
Каким должно быть хорошее API?
1) API должно быть версионировано. Все течет, все меняется: бизнес-требования, новые…
Современная разработка - это микросервисы, микросервисы - это много внешних взаимодействий, а внешние взаимодействия - это API.
Каким должно быть хорошее API?
1) API должно быть версионировано. Все течет, все меняется: бизнес-требования, новые…
Всем привет!
Сегодня хотел бы поговорить про код-ревью.
Для начала - что оно нам дает?
1) единообразие кодовой базы. Люди приходят и уходят, а код остается) Новичок в команде должен во-первых быстро разобраться в проекте, а во-вторых - писать код в едином стиле. Я говорю не только про код-стайл, но и про наименования, разделение по модулям и слоям, переиспользование кода и многое другое
2) понятный, "чистый" код в проекте. Тут можно снова сказать про важность быстрого вхождения в проект новых людей. Важная ремарка - чтобы код был простым и понятным ревьювер должен сознательно ставить себе такую цель.
3) общее владение кодом в команде. Если код посмотрел ревьювер и сделал это качественно, а не формально - этот код теперь знают два человека. Легче вносить какие-то правки, проводить рефакторинг.
4) альтернативный взгляд на решение задачи. Не всегда предложенное решение будет правильным, и нужно все переделывать. Но узнать о других вариантах и обсудить к примеру будущий рефакторинг точно будет полезно. Отдельно хочется отменить, что иногда лучше прорабатывать решение до написания кода, чтобы избежать потерь времени на код-ревью и переделывание. Примеры: новичок в коданде или просто сложная задача.
5) обмен знаниями о проекте, библиотеках, утилитах и даже языке программирования. Причем узнать что-то новое может и автор кода, и ревьювер.
6) повторяющиеся ошибки\"холиварные" вопросы на код-ревью должны обсуждаться и фиксироваться. И т.об. они являются источником для новых правил в статическом анализаторе кода и в правилах работы над проектом
И как следствие вышесказанного получаем повышение качества кода.
P.S. Далее расскажу про рекомендации для автора и ревьювера, а также про кросс-командное ревью.
#code_review
Сегодня хотел бы поговорить про код-ревью.
Для начала - что оно нам дает?
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, о чем пойдет речь дальше
Продолжаю тему 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
9) Я надеюсь, что у вас подключен автоматический prcheck - проверка PR. Если это так - не нужно комментировать то, что уже прокомментировал бот SonarQube. О том, какие замечания SonarQube правим также нужно договорится на берегу и включить в Quality Gate.
Да, о настройках DevOps для код ревью сделаю отдельный пост.
10) Типовые ошибки на код-ревью лучше проговорить со всей командой и вынести в отдельный документ или в SonarQube. Это сэкономит время в будущем.
11) Не забывайте пользоваться галкой игнорировать различие в пробелах, если ваша система для проведения ревью поддерживает такую фичу.
12) Нужно строго соблюдать scope задачи. Как бы ни хотелось поправить еще один, найденный на код-ревью баг - нельзя, это затягивает процесс. Начали с исправления бага, а закончили архитектурным рефакторингом всего сервиса - да, возможно, но не в рамках одного PR) А у нас есть Lead Time и бэклог
13) Если ревью зашло в тупик - подключайте вашего техлида, тимлида, любого авторитетного разработчика. Возможно нужен взгляд со стороны.
14) В абсолютном большинстве PR в целом код хороший. Если это не так - стоит подумать там ли вы работаете) Если вы видите крутое решение - стоит это отметить отдельным комментарием. Если просто хороший код, но с замечаниями - в первом замечании стоит отметить, что "в целом все хорошо, но..."
15) если в PR несколько однотипных ошибок, не стоит оставлять замечания на всех. Это захламляет PR. Лучше отменить одну, максимум две. А далее можно посмотреть - найдет ли автор остальные)
#code_review
Всем привет!
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение при сохранении в IDEA. Т.об. ревьювер увидит более корректный код, и ему будет проще найти серьезные ошибки, ради которых мы и проводим ревью кода.
2) не стоит отправлять на сервер код, для которого не проверена компилируемость и прохождение тестов. Да, я надеюсь ваш DevOps пайплайн это проверяет, но даже в таком случае это лишняя нагрузка на инфраструктуру, а также лишний цикл ошибка-исправление-запуск CI и замедление скорости попадания кода на тестовую среду и в конечном итоге на ПРОМ.
3) также рекомендую подключить SonarLint в IDEA и чинить баги SonarQube локально. Причины те же, что в предыдущем пункте
4) как я уже писал - ревью кода тяжелая работа. С увеличением размера кода сложность этой работы увеличивается, причем нелинейно. Поэтому декомпозируйте задачу, уменьшайте каждого размер PR. Если изменений по одной декомпозированной фиче все равно достаточно много - разбивайте PR на несколько commit. Рекомендуемый размер PR - не более 100 строк.
5) а чтобы облегчить понимание сути изменений в PR - делайте содержательные комментарии, как именно - я уже описывал в https://t.me/javaKotlinDevOps/81 Если кроме информации в отдельных commit и в тикете, по которому сделан PR, есть еще какая-то высокоуровневая логика, понимание которой важно для ревью - напишите об этом в шапке PR или отдельным комментарием к PR.
6) если ревьювер "пропал" (это плохой, но вполне реальный кейс) - постарайтесь достучаться до него по всем возможным каналам и понять причину отсутствия реакции на PR. Если оперативное ревью невозможно - найдите другого ревьювера.
7) снова о психологии) замечания к PR - это не замечания к вам лично, это замечания к вашему коду. Поэтому относится к замечаниям надо спокойно, возможно с помощью ревьювера вы узнаете что-то новое о сервисе, фреймворке, платформе или даже языке программирования. Ошибки делают все, это нормально. Главное не доводить их до ПРОМа)
8) Если копнуть глубже - ваш код на самом деле не ваш, это код команды. Вся команда отвечает за фичу. Т.е. вы с ревьювером в одной лодке, ваша общая цель - быстро вывести качественную фичу на ПРОМ.
9) как бы ни был велик соблазн пропихнуть в PR еще пару тройку мелких правок - ему нужно сопротивляться. По себе знаю, что это сложно) Но scope PR должен соблюдаться, это сильно упрощает ревью!
10) код-ревью - это диалог, а замечания - не приговор. Ревьювер может что-то не понять, не учесть или просто ошибаться. В этом случае нужно ему вежливо объяснить детали
11) ну и снова скажу что текст - ограниченный способ коммуникации. Чтобы избежать недопонимания - пообщайтесь с ревьювером лично если есть возможность, позвоните ему или поговорите по зуму
12) если PR сложный и\или работа над ним шла долго - по возможности гляньте его сами, перед тем как добавлять ревьюверов. Посмотрите именно как PR, чтобы увидеть что изменилось и что увидит ревьювер. Возможно, найдете какие-то простые баги сами или поймете, что нужно добавить комментарий
13) на замечания ревьювера лучше отвечать правками в коде, после которых они станут неактуальны, чем объяснять что-то в комментариях. Если идею сразу не понял ревьювер - очень может быть что ее не поймут люди, которые будут править этот код через год
14) и еще одна важная вещь: недостаточно просто поправить замечание в коде. Напишите что-то типа "сделано" в ответ на каждое замечание. Скажу по себе - ревьювер вам мысленно скажет спасибо!)
#code_review
Теперь перейдем к рекомендациям для авторов Pull Request (PR), они же Merge Request.
1) не нужно тратить время ревьювера на то, что могут сделать роботы) Я про чистку import и форматирование кода. Рекомендую поставить эти действия на автовыполнение при сохранении в IDEA. Т.об. ревьювер увидит более корректный код, и ему будет проще найти серьезные ошибки, ради которых мы и проводим ревью кода.
2) не стоит отправлять на сервер код, для которого не проверена компилируемость и прохождение тестов. Да, я надеюсь ваш DevOps пайплайн это проверяет, но даже в таком случае это лишняя нагрузка на инфраструктуру, а также лишний цикл ошибка-исправление-запуск CI и замедление скорости попадания кода на тестовую среду и в конечном итоге на ПРОМ.
3) также рекомендую подключить SonarLint в IDEA и чинить баги SonarQube локально. Причины те же, что в предыдущем пункте
4) как я уже писал - ревью кода тяжелая работа. С увеличением размера кода сложность этой работы увеличивается, причем нелинейно. Поэтому декомпозируйте задачу, уменьшайте каждого размер PR. Если изменений по одной декомпозированной фиче все равно достаточно много - разбивайте PR на несколько commit. Рекомендуемый размер PR - не более 100 строк.
5) а чтобы облегчить понимание сути изменений в PR - делайте содержательные комментарии, как именно - я уже описывал в https://t.me/javaKotlinDevOps/81 Если кроме информации в отдельных commit и в тикете, по которому сделан PR, есть еще какая-то высокоуровневая логика, понимание которой важно для ревью - напишите об этом в шапке PR или отдельным комментарием к PR.
6) если ревьювер "пропал" (это плохой, но вполне реальный кейс) - постарайтесь достучаться до него по всем возможным каналам и понять причину отсутствия реакции на PR. Если оперативное ревью невозможно - найдите другого ревьювера.
7) снова о психологии) замечания к PR - это не замечания к вам лично, это замечания к вашему коду. Поэтому относится к замечаниям надо спокойно, возможно с помощью ревьювера вы узнаете что-то новое о сервисе, фреймворке, платформе или даже языке программирования. Ошибки делают все, это нормально. Главное не доводить их до ПРОМа)
8) Если копнуть глубже - ваш код на самом деле не ваш, это код команды. Вся команда отвечает за фичу. Т.е. вы с ревьювером в одной лодке, ваша общая цель - быстро вывести качественную фичу на ПРОМ.
9) как бы ни был велик соблазн пропихнуть в PR еще пару тройку мелких правок - ему нужно сопротивляться. По себе знаю, что это сложно) Но scope PR должен соблюдаться, это сильно упрощает ревью!
10) код-ревью - это диалог, а замечания - не приговор. Ревьювер может что-то не понять, не учесть или просто ошибаться. В этом случае нужно ему вежливо объяснить детали
11) ну и снова скажу что текст - ограниченный способ коммуникации. Чтобы избежать недопонимания - пообщайтесь с ревьювером лично если есть возможность, позвоните ему или поговорите по зуму
12) если PR сложный и\или работа над ним шла долго - по возможности гляньте его сами, перед тем как добавлять ревьюверов. Посмотрите именно как PR, чтобы увидеть что изменилось и что увидит ревьювер. Возможно, найдете какие-то простые баги сами или поймете, что нужно добавить комментарий
13) на замечания ревьювера лучше отвечать правками в коде, после которых они станут неактуальны, чем объяснять что-то в комментариях. Если идею сразу не понял ревьювер - очень может быть что ее не поймут люди, которые будут править этот код через год
14) и еще одна важная вещь: недостаточно просто поправить замечание в коде. Напишите что-то типа "сделано" в ответ на каждое замечание. Скажу по себе - ревьювер вам мысленно скажет спасибо!)
#code_review
Telegram
(java || kotlin) && devOps
Всем привет!
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария…
Пару слов про на мой взгляд достаточно важную, но часто недооцененную штуку, как комментарии к commit-ам в git. На самом деле к любой Version Control System, но у нас же на 95+% git)))
Что должно быть:
1) комментарии обязательны
2) в теле комментария…
Всем привет!
Поговорим про инфраструктуру и DevOps, не относящуюся напрямую к ревью кода, но сильно облегчающую его проведение.
1) обязательно должна быть автоматическая проверка Pull Request (PR) на компилируемость, прохождение тестов и статический анализ кода. Одно из распространенных названий этой процедуры - prcheck. Те ошибки, что могут найти роботы - должны искать роботы)
2) обязательно должна автоматически запускаться контрольная сборка с запуском тестов после вливания кода в master\develop\release. Так мы как можно раньше локализуем проблемы, которые могут возникнуть после слияния. Несмотря на наличие prcheck и ручное ревью после слияния вполне могут появится ошибки. Особенно важен этот и предыдущий пункт если у вас не микросервис и над кодом работают несколько команд. Т.к. в этом случае ошибка, попавшая в master, заблокирует работу всех команд.
3) рекомендую сделать документ с требованиями по коду (guideline), которые невозможно автоматизировать. То, что можно автоматизировать - описывать текстом не нужно, а следует добавить в статический анализатор. SonarQube, номер один на этом рынке, дает нам кучу правил из коробки, кроме того есть дополнительные плагины с правилами, например, https://github.com/spotbugs/sonar-findbugs, а также можно создавать свои правила. Правила нужно поддерживать его в актуальном состоянии и строго им следовать. Это может быть файл в формате Markdown (.md) в Bitbucket, тогда с ним тоже можно работать через PR, либо статья в формате wiki. Главное чтобы четко было понятно, где лежит последняя версия правил
4) также должны быть правила наименования веток, PR и формата commit
5) в случае монолита будет полезным механизм, определяющий какого рода код изменился и автоматически добавляющий в PR ответственных за данную функциональную область
6) как я уже говорил ранее может быть полезен отдельный чатик для призыва ревьюверов в PR) email уведомления тоже полезны, но почту читают реже, письма могут попасть в спам
#code_review
Поговорим про инфраструктуру и DevOps, не относящуюся напрямую к ревью кода, но сильно облегчающую его проведение.
1) обязательно должна быть автоматическая проверка Pull Request (PR) на компилируемость, прохождение тестов и статический анализ кода. Одно из распространенных названий этой процедуры - prcheck. Те ошибки, что могут найти роботы - должны искать роботы)
2) обязательно должна автоматически запускаться контрольная сборка с запуском тестов после вливания кода в master\develop\release. Так мы как можно раньше локализуем проблемы, которые могут возникнуть после слияния. Несмотря на наличие prcheck и ручное ревью после слияния вполне могут появится ошибки. Особенно важен этот и предыдущий пункт если у вас не микросервис и над кодом работают несколько команд. Т.к. в этом случае ошибка, попавшая в master, заблокирует работу всех команд.
3) рекомендую сделать документ с требованиями по коду (guideline), которые невозможно автоматизировать. То, что можно автоматизировать - описывать текстом не нужно, а следует добавить в статический анализатор. SonarQube, номер один на этом рынке, дает нам кучу правил из коробки, кроме того есть дополнительные плагины с правилами, например, https://github.com/spotbugs/sonar-findbugs, а также можно создавать свои правила. Правила нужно поддерживать его в актуальном состоянии и строго им следовать. Это может быть файл в формате Markdown (.md) в Bitbucket, тогда с ним тоже можно работать через PR, либо статья в формате wiki. Главное чтобы четко было понятно, где лежит последняя версия правил
4) также должны быть правила наименования веток, PR и формата commit
5) в случае монолита будет полезным механизм, определяющий какого рода код изменился и автоматически добавляющий в PR ответственных за данную функциональную область
6) как я уже говорил ранее может быть полезен отдельный чатик для призыва ревьюверов в PR) email уведомления тоже полезны, но почту читают реже, письма могут попасть в спам
#code_review
GitHub
GitHub - spotbugs/sonar-findbugs: SpotBugs plugin for SonarQube
SpotBugs plugin for SonarQube. Contribute to spotbugs/sonar-findbugs development by creating an account on GitHub.
Всем привет!
До сих пор говоря про ревью кода, я акцентировал внимание на команде. Когда же может быть полезно кросс-командное ревью.
Основной кейс, когда внешнее ревью обязательно - над общей кодовой базой ведет работу несколько команд. Внешний ревьювер здесь играет роль независимого аудитора. Ведь правки одной команды могут что-то сломать для другой команды. Или новая команда может нарушить единообразие архитектуры.
Привлечение ревьюверов из другой команды может быть полезно, если не хватает опыта по используемой платформе или технологии.
Также кросс-ревью может быть полезно, если модули, выпускаемые командами, интегрированы друг с другом. С одной стороны может показаться, что это нарушает инкапсуляцию, которую дает нам API. Но бывают случае, когда между "соседними" командами возникает недопонимание - почему API сделано именно так или почему его стали использовать именно таким образом. Для начала в таких случаях стоит собраться и обсудить API. Если же этого мало - возможно, погружение в код соседей поможет понять причины.
Еще один вариант призыва внешнего ревьювера(ов), назовем его "пожарная команда" - если в команде в данный момент не хватает ревьюверов по причине отпуска, увольнения или набора новой команды.
И последний кейс - внешний ревьювер как арбитр для разрешения споров внутри команды. Как правило это техлид или просто опытный разработчик.
#code_review
До сих пор говоря про ревью кода, я акцентировал внимание на команде. Когда же может быть полезно кросс-командное ревью.
Основной кейс, когда внешнее ревью обязательно - над общей кодовой базой ведет работу несколько команд. Внешний ревьювер здесь играет роль независимого аудитора. Ведь правки одной команды могут что-то сломать для другой команды. Или новая команда может нарушить единообразие архитектуры.
Привлечение ревьюверов из другой команды может быть полезно, если не хватает опыта по используемой платформе или технологии.
Также кросс-ревью может быть полезно, если модули, выпускаемые командами, интегрированы друг с другом. С одной стороны может показаться, что это нарушает инкапсуляцию, которую дает нам API. Но бывают случае, когда между "соседними" командами возникает недопонимание - почему API сделано именно так или почему его стали использовать именно таким образом. Для начала в таких случаях стоит собраться и обсудить API. Если же этого мало - возможно, погружение в код соседей поможет понять причины.
Еще один вариант призыва внешнего ревьювера(ов), назовем его "пожарная команда" - если в команде в данный момент не хватает ревьюверов по причине отпуска, увольнения или набора новой команды.
И последний кейс - внешний ревьювер как арбитр для разрешения споров внутри команды. Как правило это техлид или просто опытный разработчик.
#code_review
Всем привет!
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
Поговорим про комментариях к commit.
Вот статья, где приводится пример интересного комментария: https://dhwthompson.com/2019/my-favourite-git-commit
Вообще, я двумя руками за содержательные комментарии, объясняющие что изменилось и почему.
Но этот мне не нравится)
Почему?
1) это перебор. Время, которое мы можем потратить на разработку, конечно. Соответственно, размер комментария должен быть пропорционален его важности и\или объему измененного кода.
2) для того, чтобы поделится знаниями о проблеме, комментарии git не лучший вариант. Они не индексируются поисковиками, если речь про открытые проекты Github. В случае закрытых проектов часто доступ к git-у открыт не для всех. Какой выход - написать статью или пост о решенной проблеме.
3) даже для формирования what's new такой комментарий плохо подходит, т.к. слишком большой и отвлекает внимание на себя от других изменений.
Что думаете?
#git #code_review
dhwthompson.com
My favourite Git commit
I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit.