Всем привет!
В развитие темы про готовые решения и переиспользование знаний хочу поговорить про переиспользование кода.
Ясно, что все разработчики переиспользуют готовые решения - 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.
Всем привет!
Ну и наконец немного расскажу о плохих практиках ревью кода.
Суббота. Баг на ПРОМе. Подключение из дома. Какой-то странный код, напоминающий спагетти. Много нецензурных выражений и энергичных пожеланий в адрес его автора)))
Не надо до такого доводить.
#code_review #joke
Ну и наконец немного расскажу о плохих практиках ревью кода.
Суббота. Баг на ПРОМе. Подключение из дома. Какой-то странный код, напоминающий спагетти. Много нецензурных выражений и энергичных пожеланий в адрес его автора)))
Не надо до такого доводить.
#code_review #joke
Всем привет!
Возвращаясь к вопросу отладки пайплайнов Jenkins. Я уже писал о проблеме CPS - https://t.me/javaKotlinDevOps/42
Если вкратце - весь исполняемый на Jenkins код делится на 2 вида, код А может вызывать А и Б, а код Б - только Б.
И на тестах ошибки вызова не ловятся.
Так вот - это все полбеды. Jenkins не следует очень важному принципу fail fast и часто при ошибке вызова CPS пишет warning в лог, но не фейлит джоб. Т.е. по сути не вызван какой-то метод Х из пайплайна, но джоба идет дальше. К каким последствиям это может привести - можно пофантазировать) Но что очевидно: найти корни такой проблемы сложно.
Мораль: не делайте как Jenkins)
#ci #jenkins #groovy_dsl
Возвращаясь к вопросу отладки пайплайнов Jenkins. Я уже писал о проблеме CPS - https://t.me/javaKotlinDevOps/42
Если вкратце - весь исполняемый на Jenkins код делится на 2 вида, код А может вызывать А и Б, а код Б - только Б.
И на тестах ошибки вызова не ловятся.
Так вот - это все полбеды. Jenkins не следует очень важному принципу fail fast и часто при ошибке вызова CPS пишет warning в лог, но не фейлит джоб. Т.е. по сути не вызван какой-то метод Х из пайплайна, но джоба идет дальше. К каким последствиям это может привести - можно пофантазировать) Но что очевидно: найти корни такой проблемы сложно.
Мораль: не делайте как Jenkins)
#ci #jenkins #groovy_dsl
Telegram
(java || kotlin) && devOps
Всем привет!
Чтобы после моей предыдущей статьи о тестировании пайплайнов Jenkins не сложилось впечатления, что проблем нет и провалидированный IDEA, скомпилированный и оттестированный JUnit и Pipeline Unit тестами код сразу заработает в Jenkins - вот три…
Чтобы после моей предыдущей статьи о тестировании пайплайнов Jenkins не сложилось впечатления, что проблем нет и провалидированный IDEA, скомпилированный и оттестированный JUnit и Pipeline Unit тестами код сразу заработает в Jenkins - вот три…
Всем привет!
Считается, что есть 2 мира разработки - enterprise со своими правилами, инструментами, платформами и все остальные, использующие в настоящее время в основном opensource. Я это знаю по Сбербанку, но судя по открытым источникам примерно тоже самое происходит в Яндексе, Google... Но эти два разных мира на самом деле пересекаются.
Вот список Opensource продуктов, разработанных в больших (иногда средних) коммерческих компаниях:
Google - Android, Chromium, k8s, Istio (service mesh), gRPC (RPC binary protocol), Go (lang), Angular (JS framework), Gerrit (code review), Knative (serverless platform), TensorFlow (ML), Apache Beam (data streaming platform)
LinkedIn - Kafka (streaming message broker)
Facebook - Cassandra (noSQL), React (JS framework), Thrift (RPC binary protocol)
Netflix - Eureka (discovery), Zuul (API Gateway), Ribbon (client side balancer), Feigh (http client), Hystrix (circuit breaker), Chaos Monkey (chaos engeneering)
Twitter - OAuth (auth protocol)
Amazon - S3 API (object storage API)
SoundCloud - Prometheus (metrics)
Yahoo - Zookeeper (distributed coordinator)
Yandex - Clickhouse (analytic DBMS), YDB (distributed SQL DBMS), Yandex Tank (load testing)
mail.ru - Tarantool (IMDG)
И это я перечислил известные либо уникальные продукты, о которых я знаю. Есть еще куча более мелких библиотек.
Мораль - хорошо спроектированный внутренний продукт, решающий распространённую задачу, имеет шансы стать полезным за пределами компании. Или даже мировым стандартом
#it
Считается, что есть 2 мира разработки - enterprise со своими правилами, инструментами, платформами и все остальные, использующие в настоящее время в основном opensource. Я это знаю по Сбербанку, но судя по открытым источникам примерно тоже самое происходит в Яндексе, Google... Но эти два разных мира на самом деле пересекаются.
Вот список Opensource продуктов, разработанных в больших (иногда средних) коммерческих компаниях:
Google - Android, Chromium, k8s, Istio (service mesh), gRPC (RPC binary protocol), Go (lang), Angular (JS framework), Gerrit (code review), Knative (serverless platform), TensorFlow (ML), Apache Beam (data streaming platform)
LinkedIn - Kafka (streaming message broker)
Facebook - Cassandra (noSQL), React (JS framework), Thrift (RPC binary protocol)
Netflix - Eureka (discovery), Zuul (API Gateway), Ribbon (client side balancer), Feigh (http client), Hystrix (circuit breaker), Chaos Monkey (chaos engeneering)
Twitter - OAuth (auth protocol)
Amazon - S3 API (object storage API)
SoundCloud - Prometheus (metrics)
Yahoo - Zookeeper (distributed coordinator)
Yandex - Clickhouse (analytic DBMS), YDB (distributed SQL DBMS), Yandex Tank (load testing)
mail.ru - Tarantool (IMDG)
И это я перечислил известные либо уникальные продукты, о которых я знаю. Есть еще куча более мелких библиотек.
Мораль - хорошо спроектированный внутренний продукт, решающий распространённую задачу, имеет шансы стать полезным за пределами компании. Или даже мировым стандартом
#it
Всем привет!
В каждой новой версии JDK есть изменения разной степени сложности и важности. Одно из самых важных, но на первый взгляд простых изменений, после появления которого первая возникающая мысль была: "А почему так не сделали сразу???" - это нормальный стектрейс для NPE (NullPointerException) в Java 14.
Вот еще одно похожее изменение - https://openjdk.org/jeps/445 - планируемое в 21 релиз.
Часто бывает нужно что-то быстро проверить, алгоритм или библиотеку. Т.е. у нас Java приложение из одного класса. Но нужен же метод main, а его сигнатура - не самая простая для запоминания штука. Приветствую данную фичу двумя руками)
P.S. Да, в Kotlin все еще проще - https://kotlinlang.org/docs/basic-syntax.html#creating-classes-and-instances )))
#java #java_new_version
В каждой новой версии JDK есть изменения разной степени сложности и важности. Одно из самых важных, но на первый взгляд простых изменений, после появления которого первая возникающая мысль была: "А почему так не сделали сразу???" - это нормальный стектрейс для NPE (NullPointerException) в Java 14.
Вот еще одно похожее изменение - https://openjdk.org/jeps/445 - планируемое в 21 релиз.
Часто бывает нужно что-то быстро проверить, алгоритм или библиотеку. Т.е. у нас Java приложение из одного класса. Но нужен же метод main, а его сигнатура - не самая простая для запоминания штука. Приветствую данную фичу двумя руками)
P.S. Да, в Kotlin все еще проще - https://kotlinlang.org/docs/basic-syntax.html#creating-classes-and-instances )))
#java #java_new_version
Kotlin Help
Basic syntax | Kotlin
Всем привет!
Возвращаясь к теме open source продуктов, вышедших из enterprise. Если присмотреться к списку https://t.me/javaKotlinDevOps/154 то можно заметить, что в нем нет банков. Причем не только российских - вообще никаких.
Какие могут быть причины?
1) банки любят покупать готовые, вендорские решения для того же процессинга, фрод-мониторинга, интернет-банка,... Не все, но я подозреваю многие. В этом случае ИТ команда ориентирована на поддержку, а не на разработку нового.
2) большАя часть уникальных разработок в банках связана с информационной безопасностью (ИБ). Т.е. берем open source и добавляем туда продвинутую ролевую модель авторизации, аудит, поддержку нужных стандартов шифрования... Штука специфическая, банковская, для других классов АС не нужная. В смысле ИБ нужна всем, но не всем в такой степени, как у банков. Опять же - много ИТ ресурсов уходит на доработку под требования ИБ, на другие доработки их не хватает.
3) окей, почему тогда нет рынка финансового opensource? Ну или я о нем не знаю, поправьте, если я ошибаюсь))) Т.е. никто не выкладывает финансовые библиотеки, фреймворки, утилиты на github, хотя наверняка они есть. Предположу, что это связано с банковскими требованиями по безопасности, бюрократией и консервативной корпоративной культурой. Ну т.е. просто нет такого процесса в банках. Сразу отмечу, что не стоит путать алгоритмы и фреймворки. Алгоритмы скоринга заемщика, фрод-мониторинга, расчета ставки, ... являются ноу-хау банка и никто их выкладывать в открытый доступ в здравом уме не будет. Но код, который этот алгоритм выполняет - почему бы и нет.
#opensource #fintech
Возвращаясь к теме open source продуктов, вышедших из enterprise. Если присмотреться к списку https://t.me/javaKotlinDevOps/154 то можно заметить, что в нем нет банков. Причем не только российских - вообще никаких.
Какие могут быть причины?
1) банки любят покупать готовые, вендорские решения для того же процессинга, фрод-мониторинга, интернет-банка,... Не все, но я подозреваю многие. В этом случае ИТ команда ориентирована на поддержку, а не на разработку нового.
2) большАя часть уникальных разработок в банках связана с информационной безопасностью (ИБ). Т.е. берем open source и добавляем туда продвинутую ролевую модель авторизации, аудит, поддержку нужных стандартов шифрования... Штука специфическая, банковская, для других классов АС не нужная. В смысле ИБ нужна всем, но не всем в такой степени, как у банков. Опять же - много ИТ ресурсов уходит на доработку под требования ИБ, на другие доработки их не хватает.
3) окей, почему тогда нет рынка финансового opensource? Ну или я о нем не знаю, поправьте, если я ошибаюсь))) Т.е. никто не выкладывает финансовые библиотеки, фреймворки, утилиты на github, хотя наверняка они есть. Предположу, что это связано с банковскими требованиями по безопасности, бюрократией и консервативной корпоративной культурой. Ну т.е. просто нет такого процесса в банках. Сразу отмечу, что не стоит путать алгоритмы и фреймворки. Алгоритмы скоринга заемщика, фрод-мониторинга, расчета ставки, ... являются ноу-хау банка и никто их выкладывать в открытый доступ в здравом уме не будет. Но код, который этот алгоритм выполняет - почему бы и нет.
#opensource #fintech
Telegram
(java || kotlin) && devOps
Всем привет!
Считается, что есть 2 мира разработки - enterprise со своими правилами, инструментами, платформами и все остальные, использующие в настоящее время в основном opensource. Я это знаю по Сбербанку, но судя по открытым источникам примерно тоже самое…
Считается, что есть 2 мира разработки - enterprise со своими правилами, инструментами, платформами и все остальные, использующие в настоящее время в основном opensource. Я это знаю по Сбербанку, но судя по открытым источникам примерно тоже самое…
Всем привет!
Для далекой канадской компании - разработчика лучшего в мире графического редактора, важны русские платящие пользователи: https://habr.com/ru/news/738514/
А для компании - разработчика лучшей в мире IDE, имеющей русские корни, увы, нет(((
#IDEA
Для далекой канадской компании - разработчика лучшего в мире графического редактора, важны русские платящие пользователи: https://habr.com/ru/news/738514/
А для компании - разработчика лучшей в мире IDE, имеющей русские корни, увы, нет(((
#IDEA
Хабр
Adobe решила бесплатно продлевать российским пользователям-физлицам лицензии, купленные через официальный магазин
image Американская компания Adobe решила бесплатно продлевать лицензии российским пользователям-физлицам, которые ранее купили доступ к ПО через официальный интернет-магазин. «У пользовательских...