Любая конференция — это, прежде всего, месяцы подготовки. TechLeadConf не исключение. Всё те же небольшие проекты, тысячи задач, ограниченных временем, бюджетом и технически. Куча взаимосвязанных процессов, подчинённых бизнес-логике. И потеря любого из них грозит срывом всего мероприятия. Конференция — это партнёры, подрядчики и огромная организаторская команда. Это программный комитет и докладчики. Много практики, эмоций, холиварных тем и страха… А куда без него? Все боятся, что чего-то не получится. Что не успеют, не подготовятся, чего-то забудут или плохо выступят. Но в итоге все преодолевают свой страх и делают. И получается уникальная профессиональная тусовка с пользой в основе.

Делимся лучшими по мнению зрителей докладами с TechLead Conf 2024 в Санкт-Петербурге, прошедшему в рамках TeamLead Conf++ 2024. Насколько это объективно, решайте сами.

Trunk based development: меняем подход к разработке и забываем о релизах

Срыв сроков релиза, непонятно откуда берущиеся в последний момент хотфиксы и появляющиеся из неоткуда изменения сразу в мастер-ветку. Это боль известна многим. Ручные проверки, сравнение версий и постоянный страх, что что-то пойдёт не так. Но при этом парадоксальное желание, чтобы всё быстро, автоматически улетало в прод. «Вы всё ещё кипятите? Тогда мы идём к вам!» 

Владимир Агеев Т-Банк показал, как они преодолели свой страх и справились с этой болью, пройдя путь от релиза в 2 недели до больше тысячи деплоев в год. То есть увеличение частоты релизов где-то в 40 раз. Не удивительно, что такой прогресс вошёл в ТОП докладов.

Такого крутого увеличения регулярных авторелизов удалось добиться благодаря внедрению методологии разработки программного обеспечения. Trunk Based Development предлагает использовать только одну основную ветку «trunk» для разработки и интеграции всех изменений в коде. Это позволяет оптимизировать процесс релизов до полной автоматизации релизов без ручных проверок тестировщиками.

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

Смотрите сами — https://vk.com/video-177460632_456239034?list=ln-H35ZkYixylVNRI69bp

Как рассказывать архитектурные диаграммы

Это уже история не совсем о страхе, а скорее о распространённых ошибках, которые подстерегают докладчиков и тех, кто защищает свои архитектурные решения. Хотя выступление IТ-архитектора, автора и преподавателя курсов по архитектуре Максима Смирнова будет полезно не только тем, кто часто объясняет другим архитектурные решения, но и тем, кто участвует в таком обсуждении и согласовании архитектур.

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

Кому интересно научиться полноценно представлять архитектуру перед аудиторией, смотрим видео доклада — https://vk.com/video-177460632_456239033?list=ln-LGsXjIzDuQgtZ1R6za

TDR — процесс технического дизайн-ревью

Из-за неконтролируемого роста проектов, давления бизнеса, нехватки квалифицированных кадров и их текучки в программной инженерии возникает всё больше антипаттернов. Таких как Big ball of mud, магические числа, классы и многое другое. Особенно быстро и катастрофически это проявляется при быстром увеличении масштабов текущей системы. Чтобы избежать хаоса и негативных последствий стремительного роста, нужно валидировать архитектуру.

Существует много популярных подходов. В одних компаниях начинают писать proposal’s, которые по факту мало кто читает. В других начинают писать RFC, которые трудно разыскать, но ещё труднее в них разобраться. В третьих компаниях создают архитектурные комитеты, которые не могут прийти к единому решению и ещё больше тормозят процесс.

TeamLead команды Architecture Governance в Авито Павел Лакосников поделился ещё одним подходом. Они попробовали все обозначенные выше подходы и сделали у себя внутри четвёртый, который назвали TDR (Technical Design Review). В итоге получили асинхронный формат валидации со своими шаблонами, гайдами и обогащёнными данными. Хотите узнать ещё один способ контроля архитектуры, смотрите выступление Павла — https://vk.com/video-177460632_456239035?list=ln-l5JbeYzbQyZrysveGU

Есть идея доклада, но страх публичных выступлений, неуверенность в его ценности или какие-то другие причины мешают реализоваться? Пора выходить из зоны комфорта, чтобы продолжать развиваться самому и способствовать развитию других. Мы не предлагаем покупать курсы или участвовать в марафоне желаний. У нас всё ещё проходит call for papers для TechLead Conf 2024 в Москве. До 15-го Августа принимаются заявки на участие в конференции, которая пройдет 27 и 28 Ноября. Подробности на официальном сайте TechLead Conf 2024.

Попробуйте себя! Страхи существуют для того, чтобы их преодолевать, получать новые скиллы и эмоции. А мы вам в этом поможем!