Файл для зрителей Трепа 👆

Что делать, когда бэклог переполняется техдолгом?

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

Все эти “мелкие” и “небизнесовые” задачи – технический долг. Работа с техдолгом – это баланс между краткосрочными целями бизнеса и его выживанием в долгосрочной перспективе.

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

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

🔺 Выделить спринт или несколько исключительно для задач по техдолгу.
🔺 Создать роль “дежурного”, который будет закрывать небизнесовые задачи. Передавать эту роль между членами команды раз в день/неделю/спринт.
🔺 Создать maintenance team, задача которой – исправление багов, рефакторинг и выполнение “общих” задач.

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

▫️ Донести до product owner-а или других представителей бизнеса, что нельзя бесконечно откладывать рефакторинг и создание качественной документации. Выделять 20-30% спринта на задачи по техдолгу.
🔹 Повышать квалификацию сотрудников и развивать культуру разработки. Члены команды, чьи ошибки приходится исправлять, должны, как минимум, знать об этом и стараться не повторять их.
▫️ По возможности автоматизировать проверку кода – линтеры, авто-тесты в CI/CD пайплайне и т.д. Так промежуток времени между созданием техдолга и его исправлением существенно уменьшится.

Планирование задач команды вместе с PO – функция тимлида, с которой начинающие руководители часто испытывают трудности. Нахождение баланса между потребностями бизнеса и техдолгом – одна из тем в программе курса [Team Leadership]. Старт курса – 6 августа. Успейте записаться на консультацию!

Митап об архитектуре и архитекторах

Завтра состоится Software Craftsmanship Meetup №27, на котором Павел Вейник и Антон Дворников по косточкам разберут этапы роста и развития архитектора. Митап для тех, кто уже там (в архитектурной роли) и who wanna be.

Кроме запланированной программы, спикеры ответ на ваши вопросы:

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

Чтобы на ваши вопросы точно ответили - присылайте пожалуйста их заранее, в форме регистрации. До встречи на митапе!

Поведенческое и culture fit интервью: как пройти и подготовиться

В субботу пройдет 7ая встреча из серии Career navigator for seniors. Нам по прежнему важно помогать вам с поиском работы и подготовки к собеседованиям, поэтому мы приглашаем разных экспертов tech индустрии - опытных инженеров, карьеных консультантов, HR поделиться советами и опытом как  увереннее себя чувствовать на собеседованиях и получить работа в желанной компании (или просто работу🙂)

Когда: 3 августа 11.00 по GMT+3

На встрече разберем:

1. Тренды в вопросах на интервью: поведенческие и ситуативные вопросы
2. Самопрезентация и ответы на сложные вопросы
3. Как готовиться: методы, инструменты, best practices

Спикер: Анна Писарева, экспертка в области HR и карьерного консалтинга с более чем 12-летним опытом работы в СНГ, Австралии и на международном рынке

🔗 Регистрация

Как и обещали, первая часть статьи От хаоса к стандарту: создание универсального шаблона микросервисов уже в нашем LinkedIn!

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

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

Соскучились по Архитектурным Трепам?

Мы - очень 🤗. Поэтому на этой неделе у нас их два!

1️⃣ Завтра, 6 августа соберемся поговорить на серьезные темы - как выбирать базу данных для проекта. Модерировать будет Максим Аршинов.

Правильный выбор базы данных — это ключевой фактор успеха любого IT-проекта. Как подойти к этому выбору, чтобы он был обоснованным и эффективным? На Трепе мы будем действовать как инженеры и попробуем создать исчерпывающее руководство по базам данных, которое поможет вам быстро и уверенно выбрать правильный инструмент.

2️⃣ В четверг, 8 августа, соберемся со Светой Семеновой повеселиться на тему кринжовых ситуаций в ИТ компаниях. Неожиданные и странные вопросы на собеседованиях, эзотерика, астрология и найм в компании на основании знака зодиака. А с какими странностями сталкивались вы? Приходите поделиться и поорать вместе 😁

🔗 Регистрация

⚡️На прошлой неделе мы стартанули серию От хаоса к стандарту: создание универсального шаблона микросервисов и уже подобрались к самому интересному – собственно, созданию шаблона и тому, что в него вошло.

🔗 Часть 4 уже в нашем LinkedIn. Подписывайтесь, чтобы не пропустить следующие!

Добавление ивента в календарь

Мы знаем, что у многих есть проблема с добавлением события себе в календарь. Мы проверили ещё раз и выяснили, что добавить себе событие в мобильном приложении календаря невозможно - ни на Android, ни на IOS. Гугл календарь не принимает свои же созданные события 😔 Это выглядит как системная ошибка на стороне сервиса, к сожалению, мы ничего не можем с этим сделать. Тут тоже про это писали https://stackoverflow.com/questions/63886313/google-calendar-event-link-not-opening-google-calendar-app-event-creation-with-d

Поэтому пока мы предлагаем следующее:

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

На занятии курса [Технический Лидер] один из участников задал вопрос – “Допустим, выкатили на прод версию с ошибкой и поломали всю систему микросервисов. Быстро пофиксить не удается. Как провести откат системы к работающему состоянию?” Тема интересная и на занятии мы ее рассмотрели подробно. Приводим коротко спектр доступных опций.

5 сценариев отката неудачного релиза

Когда можем себе позволить downtime:

1️⃣Сценарий – нет ни документации, ни версионирования, ни плана 😱. Придется собрать лидов и сеньоров всех команд, ответственных за неисправные сервисы. Вместе разобрать логи ошибок, локализовать их в каждом микросервисе и откатить до рабочего состояния БД. Вариант только для экстренных случаев, требует несколько часов совместных титанических усилий.

2️⃣Сценарий – есть скрипты Liquibase / Flyway, есть версионирование структуры базы. Команда каждого микросервиса отдельно от других откатывает код до старой версии. Если в процессе миграции были объемные изменения данных – в хранимой процедуре должен быть подготовлен скрипт, который производит миграцию в обратную сторону. Такой вариант занимает уже полчаса-час.

Когда нужно без downtime:

3️⃣Сценарий – запретить изменения в базу, но оставить доступ на чтение. Пользователи не могут полноценно пользоваться сервисами, но могут, например, посмотреть отчет за какой-то период. Для этого варианта нужен подготовленный фронтенд с feature flags. С клиента на бэкенд будут приходить только select, но не update. В это время можно спокойно (относительно) реализовать один из предыдущих сценариев.

4️⃣Сценарий – каждая команда делает релизы независимо друг от друга и есть реестр версий каждого сервиса. В таком случае, через средства автоматизации весь прод откатывается к последнему чекпоинту, когда комбинация микросервисов с разными версиями работала. Каждый микросервис, который обновился, откатывается до нужной версии независимо от других. За такой реестр должен отвечать кто-то над всеми командами разработки – архитектор или delivery-менеджер.

5️⃣Сценарий – в релизе сложные изменения в большой системе. Пример: меняем KV-базу на реляционную. Параллельно работают два варианта кода – со старой базой и с новой. В старую базу добавляется поле “переведено в новую БД”. Все апдейты, которые попадают в старую базу, дублируются в новую и, когда это происходит, в старой БД меняется значение этого “feature flag” каждой записи. Если с новой версией что-то не так – старая продолжает работать.

А с какими сценариями сталкивались вы? Делитесь в комментариях 👇