Чуть не забыл сделать анонс онлайн QA дискуссии от DOU, в которой я приму участие. Мероприятие запланировано на вторник 20 апреля, начало в 19:00.  Обсудим компанией из трёх экспертов одну из любимых моих тем - обеспечение качества. Все абсолютно бесплатно, трансляция на YouTube: https://www.youtube.com/watch?v=jrK_JUlir_s

#qa #конференции

Я уже много раз поднимал тему модульных монолитов, которые представляют собой нечто среднее из двух крайностей (настоящая микросервисная система и огромный единый монолит). Этот архитектурный подход отлично подходит для многих кейсов, даёт нужную гибкость для будущего развития и отличную изоляцию доменных областей.

Но для такого архитектурного подхода практически нет специализированных фреймворков. А без должного контроля разработчикам не хватает дисциплины и код все время норовит превратиться в одно большое месиво. И вроде бы все отдельные компоненты есть в Java мире:

- уровни видимости, пакеты и модули на уровне языка;
- модули и Maven и Gradle;
- поддержка агрегатов из DDD в Spring Data с возможностью генерировать доменные события;
- базовый механизм внутренних событий в Spring для слабой связности и простой интеграцией с внешними брокерами сообщений и Kafka;
- ArchUnit для контроля границ модулей в тестах;
- иерархия Spring контекстов...

И вот на днях я натолкнулся на Moduliths - площадку для экспериментов в данной области по созданию удобного фреймворка на базе Spring Boot. Очень интересные наработки, могут помочь навести и поддерживать порядок в вашем монолите.

#java #springboot #архитектура

Мне кажется, пришло время единых платформ для всей деятельности организации/департамента/команды. Я постоянно наблюдаю как люди пытаются соединить воедино кучу разрозненных инструментов и сервисов, тратя кучу энергии, денег и времени. Классический пример, который работает у многих: Asana, Jira, Confluence, Slack, TestRail, Gitlab, Jenkins... И потом на это сверху намазываются тонны плагинов, настроек интеграции и прочих пакостей. И при этом, за все эти инструменты компания платит отдельно.

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

Я не делал глобального исследования рынка, но поковырял две свежих платформы: Space от JetBrains и Fibery от Миши Дубакова (основателя Targetprocess). Space более техническая, в дополнение к управлению процессами и документацией, она интегрирует все нужные инструменты для работы с кодом и организации CI/CD. Мне прямо очень понравились обе с точки зрения фичей и простоты работы. Рекомендую взглянуть и оценить для себя. Думаю, что за этим будущее!

​​#реклама #javascript

Я снова с новостями для желающих начать свою карьеру в IT и выбирающих язык программирования для старта. У вас наверняка есть такие знакомые.

JavaScript - самый популярный язык программирования, согласно данным GitHub. На нем пишут и фронтенд и бэкенд, без него не обходится ни один современный веб-ресурс. На бесплатном вебинары GeekBrains вы разберётесь в основах JavaScript и поймете, хотите ли изучать его. Занятие будет полезно тем, кто интересуется программированием и задумывается, с чего начать.

На вебинаре вы:

- напишете простой код и запустите его в браузере;
- познакомитесь с переменными, ветвлениями и циклами;
- создадите простую консольную игру «угадай число».

Спикер:

Павел Тарасов. Ведущий веб-разработчик с опытом более 10 лет. Преподает в GeekBrains c 2016 года: провел более 300 курсов и обучил более 18 000 человек.

Доступ к новым знаниям по ссылке: https://gb.ru/link/xIKrLphttps://gb.ru/link/xIKrLp

Погода этой весной не задалась и у многих появилось больше свободного времени для саморазвития. Для Java разработчиков рекомендую глянуть крутой обзор в стиле live coding на тему Spring Cloud Gateway (реализация популярного микросервисного паттерна API Gateway). За полтора часа вы узнаете о мотивации создания этого проекта в семействе Srping Cloud, основных возможностях и особенностях применения.

Рассказчиком выступает легенда Spring мира Джош Лонг, а это значит заодно можно поучиться быстро писать код. Отличным упражнением для большинства разработчиков будет попытаться параллельно с Джошем писать код в своей локальной IDE. Тогда материал принесет куда больше пользы. Хорошей прокачки!

#java #springboot #микросервисы

https://www.youtube.com/watch?v=puIJ1Mn9_LE

Во вторник принимал участие в панельной дискуссии на тему QA от DOU. Вместо полутора часов получилось два, но зато успели обсудить много интересных тем. Кто не знал чем заняться на холодных выходных, можно посмотреть в записи. Дополнительно, под постом можно найти видеозаписи моих докладов на тематику QA и получится почти тренинг. :)

Удачного просмотра!

#qa #качество

https://youtu.be/jrK_JUlir_s

​​#реклама #jobs

Хочешь иметь возможность работать с любой точки мира и использовать современный технологический стек? Тебе интересны IoT технологии?

📆 С 21 по 27 апреля AgileVision приглашает Java-инженеров уровня Middle и Senior на Java Hiring Week. Регистрируйся на сайте, чтобы присоединиться к одному из IoT-проектов компании и получить Welcome Bonus!

Узнать больше о компании и о преимуществах сотрудничества можно здесь.

Что необходимо с твоей стороны?

✔️Заполнить форму на сайте. Ты получишь обратную связь от компании в течение 1-2 рабочих дней.
✔️Пройти HR и техническое собеседование.
✔️На следующий день, по результатам интервью, ты сможешь получить офер и 🎁 Welcome Bonus.

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

Осталось всего три дня - регистрируйся на сайте уже сейчас!

Меня часто спрашивают про мое видение современного тест менеджмента: какие инструменты использовать, какой формат выбрать, как интегрировать автоматизацию, генерировать отчеты о тестировании и т.д. Последние несколько лет я являюсь активным сторонником подхода «everything as a code» и всячески его пропагандирую не только для инфраструктуры, где это уже давно стало стандартом.

Мы уже внедрили «test cases as a code» для нескольких продвинутых клиентов (очень жаль, что не для всех) и оно работает просто отлично. Сразу в арсенале появляются все привычные разработчикам инструменты для отчетности, интеграций с чем угодно и возможности расширения под свои нужды. И такой тест менеджмент сразу automation native, что делает его на порядок более привлекательным.

У меня на данную тему ещё не было выступлений, но зато Артём Ерошенко отлично осветил ее на одной из конференций. Если интересно узнать детали, вот вам запись доклада. Приятного просмотра!

#qa #тестирование #качество

https://youtu.be/Prm2-c_5mYs

#реклама #полезные_каналы

Больше половины продуктов проваливается — команды не могут создать ценность (или найти заветный product/market fit). Но если это произошло, наступает фаза роста. А для нее нужны деньги. А значит придется идти к инвесторам.

Кому дают деньги, а кому — нет? Попросим рассказать об этом Андрея Торбичева, партнера инвестиционного фонда Месторождение (группа ТилТех), автора канала Индекс дятла.
------------------------------------------------------------

“Сколько евреев - столько и мнений”, — говорилось в старом анекдоте. С инвесторами похожая ситуация — у каждого свой подход и инструменты оценки. И все же есть несколько вещей, на которые смотрят все:

1. Рынок. “Главное - правильно выбрать стол”, — говорил Тони Шей, основатель Zappos. Если потребителей мало — неважно, насколько круто выстроен ваш продукт. Он просто не сможет расти. И да, если вы показываете нишевое решение — придется убедительно объяснить, как сможете выйти из ниши. В России интересны рынки, где есть хотя бы 10 млрд.+ рублей.

2. Конкуренты и преимущество. Если есть рынок —  значит есть и конкуренты. У кого вы будете отбирать клиентов и за счет чего — вот два вопроса, которые волнуют инвесторов. Обычно мы видим таблички с кучей галочек, где приводятся сравнения разных решений. Лучше выбрать трёх главных конкурентов и выделить ОДНО, но сильное преимущество перед ними.

3. Ключевая метрика. По опыту, рост — следствие фокуса на одной ключевой метрике.  Это может быть стоимость привлечения, retention, k-фактор и т.д. Странно, большинство фаундеров и продакт оунеров не знают ее и растят все по чуть-чуть.

4. Команда. Есть человек-продукт и человек-продажи (Hacker и Hustler). То, что называют минимально жизнеспособной командой.  Инвестировать в команды, где нет этих двух компетенций — опасно.

5. Стратегия. Это ответ на вопрос, на что конкретно пойдут деньги. Я часто слышу фразы типа “на доработку продукта” или “на рекламу”. И это не лучший способ объяснить инвестору будущий рост.

Ну и, конечно, умение все это рассказать — быстро, лаконично и понятно.

В своем канале @dindex Андрей делится наблюдениями о запуске продуктов/стартапов, поиске ценности и роста, командах и привлечении инвестиций. Кратко и без воды. Подписывайтесь!

Я дочитал очередную техническую книгу, пришло время обзора. В этот раз она была на тему современной инфраструктуры и архитектуры - «Kubernetes Best Practices». Когда я добавлял эту книгу в список для чтения, меня подкупило название. Ведь достаточно много книг, описывающих основы для старта, но мало сфокусированных на полезном практическом опыте и выученных уроках.

Начнём с плюсов:

- книга достаточно компактная, всего 250 страниц, очень легко читается;
- главы неплохо структурированы и практически не связаны, поэтому можно читать точечно по мере надобности;
- затронуты практически все аспекты работы с Kubernetes от построения кластеров до организации Continuous Delivery.

А теперь про минусы:

- не ожидайте глубокого погружения в контекст, все достаточно поверхностно и предполагает уже наличие определённых знаний и опыта;
- большинство примеров тоже достаточно поверхностны и не представляют из себя целостное связанное приложение;
- в части тем маловато тех самых best practices, даже я мог бы больше перечислить.

Резюмируя, книга подходит для прочтения тем, у кого уже есть практический опыт работы с Kubernetes. Основная цель - проверить себя на знания хороших практик и подходов в широком спектре тем, а также выделить области для более глубокого изучения. Ну и конечно же, в работе можно обращаться к книге точечно, чтобы получить полезные вводные в определенной области. Я бы рекомендовал только после более фундаментальных книг по Kubernetes.

#книги #books

Часто при внедрении автоматизации тестирования в уже существующий процесс разработки (когда она не закладывалась изначально как часть этого процесса) люди задумываются над метриками эффективности внедрения. И тут быстро становится понятно, что одним покрытием кода сыт не будешь. Для подсчета ROI автоматизации нужно понимать сколько времени сэкономлено, находятся ли реальные дефекты, какова стоимость поддержки тестов в актуальном состоянии и насколько они надёжны.

Недавно мне на глаза попалась статья на эту тему, которая может дать начальный посыл что, как и зачем можно считать. Если у вас адекватный CI инструмент (например TeamCity), то большую часть упоминаемых метрик можно получить из коробки. С остальными поможет тест менеджмент система.

А вы что измеряете в области автоматизации тестирования?

#qa #качество

В отпуске с книгами дело движется активнее. Есть свободное время и нетехническая литература быстрее читается. Следующей прочитанной книгой стала «Ловушки мышления» про то, как принимать осознанные решения, о которых не придётся жалеть.

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

Мне книга понравилась сфокусированностью, огромным количеством примеров из совершенно разных областей, хорошей структурированностью материала. Из минусов я бы отметил некоторое растягивание, но может это особенности восприятия. Если вы часто сталкиваетесь со сложными решениями по работе или мучаетесь с личными решениями, то книгу однозначно рекомендую!

#books #книги

Многие знают про проблему middle management. Она появляется когда создаётся искусственная иерархия менеджмента, в которой начинают тонуть любые решения, идущие сверху вниз или снизу вверх. Эдакий бюрократический амортизатор компании, целью которого является сбережение текущего статуса кво и своей позиции.

Сегодня я хочу поделиться своим видением и опытом на тему необходимых ролей для оптимальной разработки продукта и избегания ловушки middle management. Итак, для старта нам нужны такие роли:

1. Product Owner (PO) - лидер и драйвер со стороны бизнеса, который отвечает за продуктовую визию, наполнение бэклога, управление приоритетами и развитие продукта.

2. Solution Architect (SA) или Technical Lead (TL), который будет драйвить техническую сторону продукта, включая архитектуру, процессы разработки, инженерные практики и другие технические вопросы.

3. Команда разработки, которая будет непосредственно разрабатывать продукт, сбалансированная по компетенциям в соответствии с выбранным техническим стеком.

Очень простой и эффективный сетап, в котором бизнес и команда работают вместе максимально плотно над общими целями. Какие дополнительные роли могут появиться в таком сетапе?

4. Если бизнес-домен сложный и нужно детально прорабатывать высокоуровневые требования, то могут появиться бизнес-аналитики в помощь к PO. Это уже дополнительное звено в коммуникации между PO и технической командой. Также, может возникнуть потребность в роли Enterprise Architect, если новый продукт строится в сложном ландшафте других систем и сервисов.

5. Если нет возможности или желания нанять зрелых специалистов для построения самоорганизованной команды, а SA/TL не имеет опыта управления командой разработки, то на сцене появляется Project Manager, который берёт на себя данную задачу. Альтернативным вариантом на данном этапе является выделение роли Team Lead.

6. Если разработка ведётся по Scrum и в команде ни у кого нет нужного опыта и желания, то на сцене может появиться роль ScrumMaster (SM).

Последние 2 роли практически закрывают собой несовершенство организации, возникающее от недостатка денег, опыта или времени на построение оптимальной структуры. Это первый шаг к созданию сложной иерархической структуры, в которой PO, SA/TL, PM/TL и SM начинают делить области ответственности и влияния. А баланс этого деления будет сильно зависеть от их уровня квалификации и лидерских качеств. Могут получиться очень плохие перекосы, когда за приоритеты начинает отвечать PM или SM становится менеджером команды.

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

#менеджмент #разработка

Продолжаем рассматривать иерархии менеджмента в разработке. Ситуация начинает ухудшаться с необходимостью масштабировать разработку. В оптимальной структуре мы по-прежнему имеем роли PO и SA/TL, а все команды представляют собой самоуправляемые ячейки. Из моего опыта 3-5 команд могут легко работать по такой схеме, 5-8 уже тяжелее, больше 8 уже становится сложно. Что делают в этом случае большинство компаний? Они начинают растить иерархию менеджмента. Появляются новые роли:

7. Delivery Manager (DM), который отвечает за организацию работы нескольких команд (обычно от 2 до 5). Под ним уже находятся PM-ы или Team Lead-ы.

8. Delivery Director (DD) или Program Manager (PGM), который отвечает за организацию работы большого количества команд (обычно от 5 до 10+). Под ним находятся DM-ы.

Вот мы и построили «прекрасную» иерархию PO->DD->DM->PM/TL/SM, в которой очень быстро происходит бюрократизация процессов принятия решений и все замедляется. Для компенсации потери скорости добавляют ещё команд и все ещё больше усугубляется...

Что делать? Есть несколько альтернатив:

- разделить продукт на независимые подпродукты, например веб-приложение и мобильные клиенты;
- выделить слабосвязанные стримы;
- использовать принципы микросервисной архитектуры и строить команды вокруг доменных групп сервисов.

В первом случае структуру можно оставить максимально плоской, но обычно сложно выделить больше чем 2-3 подпродукта. Во втором и третьем могут понадобиться вспомогательные роли как Stream Lead или Domain Owner для организации работы в рамках стрима или гармоничного развития домена.

Третий подход можно использовать для масштабирования практически любого уровня.

Избегайте иерархий, за ними редко скрывается что-то хорошее!

#менеджмент #разработка

К завершению отпуска готов поделиться отзывом ещё об одной книге. Не знаю откуда она появилась у меня в списке на чтение и почему попала в топ. Видимо, кто-то сильно рекомендовал. Книга называется «Давай больше не ссориться» авторства Мишель Броди.

Мне она прямо очень понравилась, я бы даже назвал ее самой полезной книгой в этом году. Вот немного деталей:

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

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

#книги #books

​​#реклама

Очередной анонс вводного курса для начинающих (а может и не только), на этот раз на тему блокчейн и его практического применения.

Блокчейн — это уже давно не только про криптовалюту и майнинг.

Сегодня технологию используют такие гиганты, как Google, Microsoft, Amazon, Visa, Mastercard, Oracle, IBM. Компании по всему миру выбирают блокчейн, чтобы создавать надежные распределенные хранилища данных. И количество вакансий, связанных со знанием этой технологии, растет с каждым днем.

Хотите узнать больше и сделать первый шаг к профессии будущего? Тогда приходите на интенсив «Как работает блокчейн» от GeekBrains.

Вы узнаете:

➖Что такое блокчейн.
➖Как посмотреть транзакции в блокчейне.
➖Где применяют блокчейн.

Ведущий - Алексей Тетюшин, финансовый аналитик. Семь лет интересуется технологией, вместе с командой создал проект по хранению в блокчейне дипломов Финансового университета.

Записывайтесь → https://gb.ru/link/TA~-4F

​​Пятничный развлекательный пост про требования и постановку задач. Все наверняка знают историю про 7 красных линий (или будет повод погуглить). А вот эта встретилась мне только недавно:

Саня, привет. Срочно нужен баннер, в идеале через час.
Макета нет, нужно нарисовать. Идея следующая: летит по небу корова, у неё крылья, как у самолета или чайки. Подумай как лучше. В зубах она несёт ведро с раками, на ведре написано «Вкуснотища». За ней летят два крокодила и муравей с пастью как у хищника. Муравей пусть будет фиолетовым. Над всем этим радуга и в дали виднеется Родина Мать.

И слоган внизу подумай какой в тему лучше подойдёт, чтоб картинка была понятна всем и все побежали сразу ко мне в раковарню.

Ну и решение конечно же есть! ⬇️

#юмор #пятница

У меня очередной анонс полезного мероприятия для Java разработчиков (хотя, судя по программе, не только Java). JUG.RU совместно с Integrity Solutions подготовили неплохой набор докладов для вечернего просмотра.

Когда: 24 мая, 18:00 (по МСК)
Участие: бесплатно
Формат: онлайн

Программа митапа:

«Java Flight Recorder»
Алексей Рагозин о том, что такое JFR, чем он может быть полезен в работе и в каких случаях его стоит применять.

«Переезд с PostgreSQL на Elasticsearch для гибкого поиска адресов»
Александр Чернышев проведет обзор примера создания сервиса для пересылки данных об адресах между базами данных: как исследовали подходы, добивались эффективности и отказоустойчивости.

«Использование механизма текстовых шаблонов Тhymeleaf для формирования динамических SQL-запросов»
Константин Карасев расскажет об использовании шаблонов Thymeleaf и проведет демонстрацию подхода с помощью тестового приложения.

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

#java #конференция

Вчера зацепили в Scrum сообществе один из популярных мифов о бесполезности роли Solution Architect и коллективной архитектуре. Он заключается в том, что Solution Architect чисто надуманная роль и архитектура должна рождаться командой при правильных вводных и должной фасилитации. В качестве довода приводится известный пример архитектора, который только рисует диаграммы и отдаёт команде.

Я постараюсь объяснить почему это миф и почему роль Solution Architect жизненно необходима большинству продуктов. Исключение составляют очень простые продукты, стартапы на начальной фазе (далеко не все) и продукты с типовой архитектурой целого семейства решений. Ключом к пониманию проблематики является отличие архитектуры от дизайна. Под работой над архитектурой подразумеваются следующие активности:

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

Если все это сделано, то остаются только дизайн решения в рамках реализации конкретной бизнес функциональности. Например, решить какие микросервисы будут затронуты, выбрать синхронный или асинхронный канал коммуникации, обеспечить масштабирование и отказоустойчивость нового сервиса. С такими задачами должна успешно справляться команда и задача Solution Architect сводится к менторству и коучингу.

Какие навыки нужны, чтобы успешно разрабатывать архитектуру системы:

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

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

Какие проявления отсутствия адекватного Solution Architect обычно можно встретить на практике:

- архитектурные характеристики (aka quality attributes) не определены и не влияют на реализацию фичей;
- система не масштабируется под рост нагрузки и не обеспечивает нужной доступности;
- систему тяжело дорабатывать, постоянно тратится много времени и вылазят проблемы;
- все дизайн решения принимаются точечно на усмотрение исполнителя;
- структура системы не соответствует потребностям бизнеса, приходится постоянно вставлять костыли;
- никто не может объяснить почему было сделано так как сделано...

Чаще всего, следующей ступенькой роста разработчика является роль Technical Lead. В этой роли он начинает развивать широту знаний и терять часть hands-on навыков. Нужно много чего изучать, читать, пробовать, экспериментировать... Это промежуточный этап развития в направлении Solution Architect.

Надеюсь, мне удалось вас убедить и кого-то даже заинтересовать новым направлением развития.

#архитектура

Существует 2 способа учиться на ошибках: делать свои или изучать чужие. Мне попалась на днях отличная статья от архитектора SoftServe про реальные ошибки из области архитектурных решений на базе AWS. Несколько обобщенных выводов от меня:

1. Правильная цепочка принятия решений выглядит так: стейкхолдеры -> бизнес потребности -> архитектура -> технологии -> реализация. За первые 3 отвечает архитектор. Если он привлёк не всех стейкхолдеров, не выявил все архитектурные характеристики и не задал всех возможных вопросов, то дальше все может быть очень печальным. Поэтому роль архитектора такая ключевая.

2. Технологический хайп сильно влияет на цепочку из предыдущего пункта. И тогда решения начинают извращаться и драйвиться технологиями, а не бизнес потребностями. Это опасный путь к переплате и разочарованию в этих самых технологиях, потому что они применяются в формате стрельбы из пушки по воробьям.

3. Все технологические решения в IT - это выбор и поиск баланса. Нет идеальных решений, для любого найдутся плюсы и минусы. Очень важно их явно собирать и обсуждать в момент принятия решения, а также фиксировать в качестве рисков на будущее. Многие технологии и решения преподносятся в индустрии сейчас как однозначно выгодные и люди даже не задумываются о минусах, пока не становится слишком поздно.

Приятного прочтения!

#архитектура