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

Тимлид или техлид

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

На самом деле, в здоровой команде тимлид (Engineering Manager) и техлид (Tech Lead) это две части одного целого. Типа инь-янь.

Го разбираться.

▫️Тимлид (Engineering Manager)

В фокусе - люди и процессы. Его задача создать среду, в которой инженеры могут максимально эффективно работать и расти, по сути отвечая на вопрос: «Как мы работаем?».

У него может быть много 1-1, встречи с HR по найму, встречи с продактами по планированию на квартал (год) вперед, либо например планирование спринта с командой. Также могут быть даже собесы на разные позиции, обсуждение бюджетов команды или Performance Review.

По таскам в том числе могут быть: найм, онбординг и увольнение, развитие и мотивация команды, решение «человеческих» проблем (выгорание, конфликты, низкая вовлеченность). Также устранение блокеров, выбивание ресурсов, взаимодействие с другими командами и коммуникация со стейкхолдерами.

▫️Техлид (Tech Lead)

Здесь в фокусе качество продукта. Его задача - обеспечить техническое совершенство, надежность и масштабируемость того, что делает команда. Он отвечает на вопрос: «Что и как мы делаем?».

Если у тимлида больше менеджерский работы, то у техлида среди встреч может быть: обсуждение архитектуры новой фичи с командой (System Design), сессия парного программирования с джуном, рассказ о последних иследованиях, которые могут пригодиться для проекта. Также может быть встреча с оптимизацией бэклога/техдолга, обсуждение проекта, выступление на внутреннем митапе, и даже забитые слоты под 2-3 часа написания кода (Deep Work).

Из области ответственности техлида можно выделить архитектурные решения, мониторинг, стандарты ревью и кодинга, тестов и CI/CD. Обязательно присутствие ока от техлида на ревью критически важных частей кода и участие в решении сложных технических проблем и инцидентов. Сверху присыпаем менторство и техническое развитие инженеров.

▫️Власть

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

▫️Скиллы

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

С точки зрения техлида я бы упомянул глубокое знание специфики работы и технологий, System Design, архитектурные паттерны, умение декомпозировать сложные задачи, навыки менторства и способность четко доносить сложные технические идеи.

▫️Итого

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

Го огонечки за техлида, сердечки за тимлида

#softskills #career

Откуда техлиду набраться знаний?

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

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

Ну камон, это мы еще до техлида не дошли

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

Наша задача теперь:

▫️Не просто знать технологию, а понимать глубинно или иметь эксперта в команде
▫️Понимать, решит ли она бизнес-задачу
▫️Сообразить, как она впишется в текущую архитектуру и сколько будет стоить ее внедрение и поддержка
▫️Сможет ли наша команда с этим работать

Паганини стал дирижером

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

Где это ботается:

1️⃣Блоги технологических гигантов, например Netflix, Uber, Dropbox, Spotify, Martin Fowler's blog - это скорее не про теорию, а про ее практическое применение. Ну вот прикиньте, буквально сейчас ребята находят решения для проблем, с которыми мы столкнемся через пару лет. Читаем про их ошибки, миграции и архитектурные решения и получаем бесплатный опыт.

2️⃣Архитектурные книги и курсы. Про теорию тоже не забываем: "Чистая архитектура" Роберта Мартина, "Проектирование высоконагруженных систем" Мартина Клеппманна. Ботаем принципы, которые с высокой вероятностью будут актуальны и через 10 лет.

3️⃣Ну и условные агрегаторы типа Hacker News, Reddit (r/programming, r/technology), профильные Telegram-каналы. На своем опыте знаю, что нереально читать всё подряд, но хотя бы пробежаться по самым интересным метриалам - самое то. Что обсуждают? Какая технология постоянно на слуху? Типа держим руку на пульсе.

4️⃣Доклады с конференций я вынес вообще в отдельную плоскость, потому что по сути в интернетах про допустим дизайн систем можно найти много инфы типа "Introduction to ..." или "Why we built ...". А если еще и найдется доклад с практическим опытом, то его можно просто перенести на наши проекты.

Кстати, по одному из моих докладов про прогнозы один человек даже дипломную работу защитил

5️⃣Делегировать мы с вами тоже не забываем, потому что можно сойти с ума все изучать всё самому. Проще вот так: "Ребята, давайте выделим 2 дня на исследование новой системы очередей. Вася, посмотри на RabbitMQ, Петя — на Kafka. В пятницу жду от вас короткую презентацию с плюсами и минусами для нашего проекта". И ребята развиваются, и мы самую мякотку изучаем.

6️⃣Кстати, доклады с конференций я упомянул, а вот сам нетворк на конфах нет. В чем прикол - там есть кулуары. Доходим до интересующего спикера ии спрашиваем: "Мы думаем внедрить X, какие подводные камни нас ждут?" Один такой 15-минутный разговор >> месяцы работы.

7️⃣Последним пунктом я бы предложил самим выстраивать в компании культуру обмена опытом. Например, регулярные встречи, где разработчики будут делиться опытом. Кто-то на досуге поковырял Rust? Кто-то копался в либке на гитхабе и нашел интересные Issues. Отлично, пусть расскажет остальным.

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

А где вы находите новые знания и как справляетесь с потоком информации?

@teamleadosh

#career

Техлид: Проектирование и Требования
Часть 1

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

Будучи техлидом, мы открываем таск трекер, а там что-то типа "Сделать с нуля систему рекомендаций для корзины". Ну и типа все. Когда-то добавили эту задачку в бэклог, забыли, и вот по сути этот эпик добрался до проектов в Q3 (как раз сейчас конец сентября). Ничего дополнительного, никаких подсказок. Очевидно, что бизнес чего-то ожидает, и скорей всего, что система будет "быстрой, надежной и масштабируемой". Ну типа как и всегда должно быть.

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

Простого решения через чтение блогов от пацанов с Netflix'а уже недостаточно. Наша задача здесь превратить неопределенность в обсуждаемый и верифицируемый план (по сути определение неопределенности, или другими словами стратегия). Это и есть наш архитектурный фундамент. Давайте его зальем.

1️⃣Нефункциональные требования

Идем и собираем от своих продактов и заказчиков их неокторые абстрактные пожелания. Далее все эти хотелки мы переводим в человеческий технический язык. Что значит "Система не должна тормозить"? Для бухгалтера, грузящего в эксельку данные для годового отчета, подождать 10 минут - это торможение?. Для юзера интернет-магазина подождать загрузку рекомендаций к корзине 200 миллисекунд - это ок или нет?

То есть первостепенно нам нужно перевести бизнес-требования на язык измеряемых инженерных метрик. Это называется формализацией нефункциональных требований (Non-Functional Requirements). Без них любое архитектурное решение может быть субъективно (однозначно) и оторвано от метрик.

Какие могут быть типичные примеры

▫️"Система должна быть быстрой" → "99-й перцентиль (p99) времени ответа для эндпоинта /api/v0.1/recommendations должен быть не более 300 мс"
▫️"Система должна быть надежной" → "Доступность сервиса (Availability) должна составлять 99.99% (это допустимые ~52.6 минуты простоя в год). Время восстановления после сбоя (MTTR) - не более 5 минут"
▫️"Система должна выдерживать нагрузку в пик спроса" → "Система должна обрабатывать до 5000 RPS (requests per second) без деградации времени ответа"

Тут же задаем вопросы:

▫️Как мы поймем, что достигли успеха?
▫️Что произойдет, если ответ будет идти 1 секунду вместо 100 мс?

Эти цифры (SLO — Service Level Objectives) станут нашим главным критерием при выборе между Kafka и RabbitMQ, монолитом и микросервисами, SQL и NoSQL.

2️⃣Дизайн-док

"Помните, 2 года назад мы решили использовать FastApi, потому что REST был слишком медленным?» - рассказывает синьор на встрече. В ответ - тишина. Никто не помнит, скорее никого еще в компании на тот момент не было. Решение на словах, дальше рифму не знаю, но вы поняли.

Внедряем культуру RFC (Request for Comments) или Architecture Design Document. Делаем вид, что это не бюрократия, но в реале это нам потом поможет, и не раз. Ведь архитектура - это по сути одни компромиссы.

Предполагаемая структура:

✏️Проблема - что мы решаем и для кого? Какие NFRs мы должны удовлетворить?
✏️Альтернативы - другие 2-3 реалистичных подхода. Например, рекомендации популярного, алгоритм на factorization matrix, ARGUS
✏️Решение - детальное описание выбранного варианта. Вот прям схемы, диаграммы последовательности, API контракты
✏️Трейдоффы - почему предлагаемое решение лучше других в нашем контексте? Какие у него минусы?

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

@teamleadosh

#career

Техлид: Проектирование и Требования
Часть 2

2️⃣Продолжаем с дизайн-доком

Сюда еще можно докинуть ADR (Architectural Decision Records) - короткие markdown-файлы в репозитории, каждый из которых описывает одно важное архитектурное решение.

Шаблон ADR:

✏️Заголовок: Выбор PostgreSQL в качестве основной базы данных
✏️Контекст: Нам нужна строгая консистентность данных (ACID-транзакции) для финансовых операций. Команда имеет глубокую экспертизу в PostgreSQL
✏️Решение: Мы используем PostgreSQL
✏️Последствия: Мы принимаем, что горизонтальное масштабирование на запись будет сложным и дорогим. Если нагрузка на запись превысит X, нам потребуется пересмотреть это решение
✏️Статус: Принято

Когда через 2 года молодой стажер спросит синьора: "Почему мы не взяли Cassandra?", тот просто отправит первого читать ADR. Одновременно страхуемся от постоянного пересмотра принятых решений. Стоит отметить, что всех проблем это все равно не решит.

3️⃣Прототипы

Допустим, мы не можем заранее понимать, выдержит ли ClickHouse нагрузку на наши аналитические запросы? И как там вообще по сложности интегрироваться? А вдруг это legacy?

Находим в телеге разработчика КликХауса и пишем ему. Короче, есть методы Spike (прототипирование) - это короткая, ограниченная по времени (обычно 1-3 дня) задача, чтобы зарисечить и проверить конкретную гипотезу, чтобы снизить техническую неопределенность. Ну или по народному - рисеч.

▫️Задача на входе: "Написать скрипт, который эмулирует нашу пиковую нагрузку на запись в YDB. Цель - проверить, укладываемся ли мы в SLO по latency"
▫️На выходе главное не рабочий код, а понятный вывод: "Да, укладываемся" или "Нет, тестим другую технологию/подход"

Ну и несколько таких спайков (рисечей по-народному) позволят нам прям прояснить затемненные участки карты принятия решений. Еще раз напоминаю, что это не гарантирует 100%-ую правильность принятия архитектурных решений.

Идеальную архитектуру из головы нам никто не выдаст. Поэтому приходится быть челом, который вносит в процесс структуру и ясность. Начинаем с малого: сформулировать хотя бы один измеряемый NFR, набросать легкий Design Doc. И все. Мы профессиональные инженеры.

@teamleadosh

#career

Техлид: Контроль и Ревью

Мы написали идеальный Design Doc. Все согласились и разошлись по задачам в своих зонах ответственности

Пошла вода горячая фаза активной разработки

Проходит пару месяцев, ну ладно, полгода. Мы заглядываем в код и видим, что модуль domain почему-то напрямую лезет в Redis. Новый микросервис должен был быть независимым, но в коде намертво завязан на базу данных соседа. А если вечером в пятницу вечером все ебанет, то может пройти много времени до выяснения, в каком из пяти сервисов произошел сбой.

Что случилось? Случилась реальность

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

Что делаем:

1️⃣Архревью

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

▫️Выделяем один час в неделю на "Design Review". Это открытая встреча, куда любой разработчик может принести свой Design Doc для обсуждения до написания основного объема кода.
▫️Цель - помочь улучшить решение. Не токсичим, а задаем правильные вопросы: "А что если этот сервис ляжет?", "Как мы будем это масштабировать через год?"
▫️Создаем коллективную ответственность. Если решение окажется топовым, то затащил не автор, а вся команда, которая его обсуждала. Также и наоборот, главное не пережестить, иначе будет страшно пробовать новые подходы.

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

2️⃣Автотесты

Тут это еще до нас придумали наши деды. Делаем проверки в CI/CD-пайплайне - автоматизированные тесты, которые проверяют соблюдение наших архитектурных принципов:

▫️Проверка зависимостей - тест, который падает, если код из слоя domain пытается импортировать что-то из слоя infrastructure
▫️Проверка на утечки или ограничения - никто не ходит в базу данных напрямую, либо в коде нет чьих-то токенов или SECRET_KEY. Подробнее тут
▫️Проверка NFRs - нагрузочный тест, который падает, если p99 времени ответа ключевого эндпоинта превышает установленный нами SLO (например, 300 мс)
▫️Проверка контрактов - убедиться, что два микросервиса по-прежнему понимают API друг друга. Подробнее тут

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

3️⃣Мониторинг

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

Наша задача как техлида на каждом Design Review получить ответ на три момента:

▫️Список метрик. Как мы поймем, что этот сервис здоров и работает? Какие ключевые бизнес и технические метрики? Например, количество запросов, время ответа, процент ошибок
▫️Структура логов. Это чтобы понимать, почему происходят ошибки. Логи должны быть структурированными (например, в JSON), содержать айдишники для отслеживания запроса и иметь достаточно контекста для диагностики
▫️Трассировка запросов для микросервисов. Понять, где именно завис запрос, который проходит через три сервиса. Подробнее тут

Просто берем и настраиваем дашборды, алерты и трассировки сразу с выкаткой основной фичи.

Короче, на уровне техлида важно уже построение отказоустойчивой системы не только в коде, но и в процессах. Что делать дежурному, какие мероприятия проводить при алертах. Когда откатываться к прошлому релизу и от кого получить ОКи.

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

@teamleadosh

#career

Техлид: Стратегия Архитектуры

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

Проходит год

В сервисе 20 новых фич, из прошлой команды осталось пару челов, код начал напоминать спагетти, при этом существует миллион тестов. Узнали? И вот что: работа не заканчивается после релиза, она только начинается. Самая идеальная архитектура как минимум обречена на деградацию

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

1️⃣Технический долг

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

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

Что с ним можно делать я подробно писал тут, но давайте вспомним основные моменты:

▫️Классифицируем - не весь долг одинаково вреден. Мы сделали это намеренно, чтобы успеть, или это просто получилось из-за спешки/неопытности? Мы понимали риски, или просто делали на шару?
▫️Обозначаем - создаем задачи на погашение, маркируем их специальным тегом (tech-debt) и складываем в бэклог. Это делает проблему видимой для всей команды и менеджмента
▫️Приоритизируем - Какой долг самый дорогой? Тот, который замедляет разработку самых важных бизнес-фич. То есть оптимизируем то, что команда трогает каждый день. И обязательно под это выделяем фиксированный процент времени в каждом спринте (например, 15-20%)

Это не про написание идеального кода, а про экономику разработки

2️⃣Легаси

Перед нами старый монолит. Он работает, приносит деньги, но каждая новая фича в нем — это боль и страдания. Каждый месяц приходят ребята с предложениями все переписать с нуля. И это очень опасная ловушка, потому что вероятность доведения до конца не 100%

Если погуглить, мы найдем понятие "эволюционная модернизация". И сразу один из самых мощных паттернов для этого - Strangler Fig Pattern.

Что делаем:

▫️Ставим прокси, чтобы ходить в старую систему через него. Изначально он просто проксирует все запросы в старую систему (фасад)
▫️Новую функциональность (или переписываемый кусок старой) мы реализуем в виде отдельного, нового сервиса
▫️В конфигурации фасада мы меняем одно правило: запросы, относящиеся к новой функциональности, теперь идут на новый сервис, а все остальные по-прежнему на старый.

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

3️⃣Связность и зацепление

В нашей зоне ответственности вся архитектура. И здесь иногда возникают моменты с гибкостью: высокое зацепление (Coupling) и низкая связность (Cohesion).

🌟Зацепление (Coupling): Насколько сильно два компонента (модуля, сервиса) зависят друг от друга. Если изменение в сервисе А постоянно требует изменений в сервисе Б - у нас высокий Coupling
🌟Связность (Cohesion): Насколько хорошо код внутри одной компоненты связан общей задачей. Если один микросервис отвечает и за профили пользователей, и за расчет доставки - у него низкий Cohesion

Что делать:

▫️Анализируем, какие сервисы чаще всего меняются вместе. И даже когда один сервис ходит в базу данных другого
▫️Определяем границы. Например, сервис "Заказы" не должен знать, как работает "Склад", их общение должно идти через четкие, публичные API.
▫️Визуализируем - строим карту зависимостей между нашими сервисами. Иногда просто по схеме можно найти архитектурные проблемы

Все понятно

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

@teamleadosh

#career

Техлид: CI/CD

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

Здравствуйте ручные процессы

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

Знакомо?

Архитектура живет и развивается только тогда, когда изменения можно вносить быстро, дешево и безопасно. А за это отвечает автоматизация, или наша CI/CD-система. Это та самая DevOps-штука, на которую нанимается целый чел, или даже два. И этой штукой нам надо уметь управлять.

1️⃣Continuous Integration (CI)

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

▫️Жизнеспособность: например, тесты, которые проверяют, что слой domain не лезет в infrastructure. Чтобы коллега при нарушени архитектурного принципа узнал об этом через 5 минут после коммита, а не на ревью через два дня.
▫️Безопасность: автоматические сканеры уязвимостей и проверку зависимостей на известные дыры. Дпоплнительно смотрим токены и секреты.
▫️Рутина: проверка стиля кода (linting), тесты, сборка билдов. То есть освобождение времени команды на code review, чтобы не искать пропущенные точку с запятой.

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

2️⃣Continuous Delivery (CD)

Реализуем изменения в продукте и архитектуре, не останавливая бизнес.

Если CI это контроль качества на заводе, то CD - это автоматизированный конвеер до потребителя. А ручные релизы - прошлый век. Как сделать релиз настолько скучным и обыденным событием, что его можно будет доверить роботу?

▫️Микро-релизы: выкатываем маленькие изменения в прод несколько раз в день, поэтому найти и исправить ошибку гораздо проще, чем когда мы раз в месяц выкатываем 20 фич сразу.
▫️Стратегии развертывания: canary deployment - выкатываем новую версию на небольшой процент пользователей, смотрим на метрики (время ответа, ошибки) и постепенно увеличиваем процент. blue-green - поднимаем рядом с текущей (blue) версией новую (green), и переключаем трафик на новую, а старую держим наготове.
▫️Откат: Нужно уметь откатывать версию одной кнопкой, чтобы не бояться релизов.

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

3️⃣Система контроля версий

Git в реале не просто способ хранения кода. Это что-то типа летописи всех инженерных решений.

▫️Храним наши Architecture Decision Records (ADR) и легковесные Design Docs в markdown-файлах прямо в репозитории. Когда будем смотреть на код и задаваться вопросом "зачем мы это сделали?", то сразу можно найти ADR, объясняющий почему было принято такое решение.
▫️Стратегия ветвления тоже влияет на архитектурный процесс. Либо Git Flow с его долгоживущими ветками (develop, feature) для продуктов с редкими, плановыми релизами. Либо Trunk-Based Development (TBD), где все коммитят в одну основную ветку, что неплохо сочетается с CI/CD.

Скорее всего те стандарты работы с Git, которые есть у вас в компании, уже подходят под необзодимые цели развития продукта. Тут скорее надо объяснить команде, как коммиты, пул-реквесты и ветки связаны с общим процессом поставки ценности.

CI/CD и Git по сути некоторая автоматизация всей нашей эволюции архитектуры, и конкретно в этих моментах техлид инвестирует в скорость, качество и, самое главное, в способность своей системы адаптироваться к будущему. Ну а дальше другие вызовы!

@teamleadosh

#career

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

UPD. Если что, скоро закончим цикл с техлидами и переключимся на менее технические и более софтскилловые моменты

Как техлиду выйти за рамки

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

Технологии и инструменты уже не для прокачки себя самого. Они только для реализации стратегии. И вот как это может поменять наше видение работы:

1️⃣"Закрывать таски" ➡️ "создавать рычаги"

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

▫️Пишем первую реализацию нового паттерна сами. Просто шаблончик или верхнеуровневая архитектура, к которому команда или гпт смогут возвращаться. Буквально на своем примере - хоп, и набросали
▫️Снижаем риски через Proof of Concept. Команда сомневается в каком-то решении? Берем и устраиваем соревнование пишем легкий прототип на своем примере, чтобы проверить гипотезу - ребята дальше докрутят сами
▫️Прыгнуть в самый сложный баг или рефакторинг, который все боятся трогать. Необязательно даже полностью самому решить его, важно просто найти узкие моменты и предложить варианты решения проблемы
▫️Растить коллег через правильно выстроенный Code Review. Через него мы менторим и обеспечиваем качество

2️⃣"То, что модно и молодежно" ➡️ "То, что выгодно"

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

▫️Решает ли новая таска бизнес-задачу или уменьшает техдолг?
▫️Сколько это стоит на самом деле? С учетом найма, обучения, поддержки в 3 часа ночи и сложности интеграции?
▫️Как это вписывается в наш технологический стек?

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

3️⃣"Глубинное знание" ➡️ "Широкое понимание"

Синьор знает свою область очень глубоко (I-shaped). Техлид должен иметь широкое понимание всей системы и связей между ее частями, чтобы предвидеть проблемы на стыках компонентов: тут скорее T-shaped или M-shaped. В современном мире я думаю мы все потихоньку становимся M-shaped. Как прокачивать широту:

▫️Держим архитектурную диаграмму (C4 Model) в актуальном состоянии
▫️Держим себя в курсе инцидентов (Post-mortems)
▫️Почитываем чужие ADR-ы в разных частях системы (либо слушаем на демо), даже если мы не ревьюим эту часть

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

@teamleadosh

#career