TechLead Conf 2020 Онлайн-конференция

Михаил_1 · 16 май 2020

Складчина: TechLead Conf 2020 Онлайн-конференция

Доклады

Между двух огней: разработка и бизнес
Артур Дементьев (Директ кредит)

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

Борьба между бизнесом и разработкой — одна из самых распространённых проблем в IT-индустрии. Первым нужна скорость в проверке решений, а вторым — чёткое ТЗ, чтобы правильно проектировать эти решения. В своём докладе я расскажу, как можно сочетать эти на первый взгляд взаимоисключающие вещи, а также несколько поучительных историй про выброшенные в помойное ведро результаты многомесячной разработки, перегибы в ту или иную сторону, костыльный код в продакшне и цену ошибочных решений, которые принимает техлид.

Как исправить сотни ошибок в legacy-коде и не умереть (на примере Unreal Engine 4)
Георгий Грибков (PVS-Studio)

Представим ситуацию: у вас имеется большой и взрослый проект с legacy-кодом. Вы установили статический анализатор, проверили код вашего проекта и получили отчёт о найденных ошибках. Сколько там их будет? По нашей статистике – несколько тысяч. Я расскажу вам, как исправить такое количество ошибок, затратив на это минимум ресурсов.

Мой доклад будет посвящён наиболее полезным практикам применения статического анализа, которые помогут вам не только справиться с ошибками в старом коде, но и не допускать появления ошибок в новом. Изложенные мной советы будут подкреплены историей о том, как два наших программиста исправили почти 2000 срабатываний статического анализатора в исходном коде Unreal Engine 4 всего за 17 рабочих дней.

Как "продать" технические задачи бизнесу
Алексей Дерюшкин (Better Life Company)

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

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

Фрактальное тестирование
Дмитрий Карловский (1С)

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

Платформенные команды — это важно. Почему?
Дмитрий Вишин (goods.ru)

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

Graceful degradation testing: тестирование частичной недоступности
Фрол Крючков (Авито)

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

Платформенная команда и 4 злобных енота
Елизавета Голенок (МТС)

Десятки продуктов, сотни пилотов, и всем нужно одно и то же. Кто-то делает inner-source, кто-то выделяет платформенные команды. Создать платформенную команду мало. Нужно суметь её не развалить до того, как платформой начнет кто-то пользоваться.

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

Круглый стол "Платформенные команды: польза или вред"
Филипп Уваров (Spotify)
Андрей Александров (Mafin)

Во время круглого стола обсудим животрепещущие вопросы про платформенные команды:
* Зачем они нужны? И нужны ли вообще?
* Почему в последнее время стало так модно создавать платформенные команды?
* Есть ли от них польза или это хайп?
* Почему выбор происходит в пользу платформенных команд, а не в сторону inner source?
* Какие проблемы плодятся платформенными командами и где можно "подстелить соломки", чтоб не повторять типичные проблемы?

Как оценить чистоту архитектуры
Денис Цветцих (EPAM)

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

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

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

Governance as a code: как соблюдать стандарты разработки и не тормозить доставку фич
Александр Токарев (Сбербанк)

При разработке крупных программных продуктов, даже применяя Agile-подход, надо обеспечить соблюдение архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Оптимальным способом решения данной задачи является подход governance as a code. При данном подходе правила проверки каждого артефакта — будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD — описаны специальным кодом проверки правил, имеют свой жизненный цикл, подвержены тестированию и ничем не отличаются от обычного программного продукта.

Мы расскажем, как и что можно проверять в процессе разработки программного обеспечения, как данный подход позволяет разрабатывать более безопасные и качественные приложения и почему было решено не использовать такие очевидные решения, как SonarCube, а разработать собственное решение на базе Open Policy Agent без дополнительных пакетов над ним.

Моделирование микросервисов с помощью Event Storming
Сергей Баранов (ScrumTrek)

При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.

Что надо сделать, чтобы изменения прижились в команде
Дмитриий Масленников (Тинькофф)

Дарвин выяснил, что выживает самый приспособленный.

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

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

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

Что нам стоит создать техноплатформу? Пошаговый гайд от идеи до внедрения
Филипп Бочаров (МТС ИТ)

Сегодня МТС — это крупная ИТ-компания, реализующая проекты в самых разных областях от телемедицины до IoT. Появление все новых продуктов стимулирует спрос на ускорение и удешевление их создания. Это возможно только благодаря повсеместному внедрению лучших инженерных практик.

Внедрение новых подходов в рамках одной команды — это захватывающая и сложная задача. А что, если таких команд 300? В реалиях крупных ИТ-компаний внедрение сталкивается с дополнительными трудностями: наличие legacy-решений, разный уровень и процессы у команд, необходимость обосновать инициативу понятным бизнесу языком.

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

“Быстро поднятое упавшим не считается”: как мы строили работу с техническими инцидентами
Дима Кузнецов (Skyeng)

У нас было 30 команд, все пилили свои сервисы — иногда они падали, цепляли друг друга по пути … “Быстро поднятое упавшим не считается”, — слышали мы и продолжали падать снова. Мы не знали, сколько денег теряем, и надеялись, что “виновные” сами разберутся в Slack.

В начале 2020-го мы стали собирать статистику по инцидентам. Столкнулись с кучей проблем по ходу внедрения общего процесса работы с ними. И уже смогли найти и исправить несколько системных проблем с важными для бизнеса сервисами. Я хочу рассказать про этот опыт:
- как мотивируем команды не хоронить инциденты в чатах, а фиксировать их. И какой лайфхак используем, если команды не хотят “выносить сор из избы”;
- как мы проводим анализ инцидентов, чтобы точечно “отлавливать” системные ошибки, решение которых принесет максимальную пользу;
- и какие результаты это приносит.

Как переехать на новую технологию, чтобы 70+ разработчиков ничего не заметили
Евгений Дашкевич (Яндекс)

Расскажу, зачем может понадобиться обновлять технический стек в крупном проекте и что может помочь в организации этого процесса. В качестве примера — реальная история перевода на React и TypeScript проекта, в который коммитят около 70 человек в день. Проекта, который рендерит миллионы разных комбинаций поисковых результатов в день — поисковой выдачи Яндекса.

Не боги горшки обжигают. Стандартизация инфраструктуры
Илья Митруков (Технологический Центр Дойче Банка)

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

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

Это доклад не про технологический Космос или пайплайны CI/CD. Это доклад про инфраструктурный быт и проекты длиной в пару лет, а также про минимизацию затрат и поддержку бизнес-деливери.

Agreements as Code: как отрефакторить процессы и не сломаться
Лев Гончаров (T-Systems)

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

В докладе я поделюсь несколькими историями, которые помогут слушателю сделать инфраструктурные процессы явными и ускорить их.

Эволюционная инфраструктура
Александр Тарасов (ANNA Money)

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

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

Баланс противоречий. Выбор лучших практик в коде и в команде
Глеб Лобастов (OneTwoTrip)

В докладе рассмотрены подходы к написанию «хорошего» кода — понятного и удобного в поддержке.

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

---

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

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

Как стать хорошим техлидом
Владимир Горовой (Яндекс.Вертикали)

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

Эффективная система мониторинга, или Как узнавать о проблемах в сервисе до того, как тебе пришлют тикет пользователи
Михаил Мазеин (ManyChat)

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

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

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

CI/CD-пайплайны на BPMN
Александр Коротков (Циан)

Мы в Циан стараемся автоматизировать любые действия, которые повторяются больше трёх раз. В CI/CD, например, нам нужно, чтобы автоматизация "рулила" почти всем жизненным циклом задачи, начиная с момента заведения тикета в Jira. Это и работа с пулл-реквестами, исходным кодом, проведением ревью, автотестами, и выкладка в прод (зачастую без участия человека). Сначала мы описали все это кодом. Получился монолит, поддержка усложнилась. Как разделить такой монолит? Как эффективно управлять процессами? Мы выбрали BPMN-движок от Camunda. Почему его, как мы переезжали и что из этого вышло, я расскажу на докладе.

Story Mapping + BDD = Docs As Code?
Денис Олейник (Один Сервис. Внедренческий центр)

BDD как концепция существует с 2006 года. За это время методика, по идее, должна была бы уже прижиться и стать стандартом де-факто.

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

Но вот почему-то в нашем домене ERP-систем истории BDD-успеха на поверку оказываются очередным набором UI-тестов, написанных постфактум.

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

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

P.S.
По ходу доклада я буду использовать такие слова, как: BDD, Living Documentation, "Docs As Code", Impact Mapping, Story Mapping, Scrum, Kanban, Jenkins, Allure и другие термины из лексикона Agile-коучей. Но никакой инфо-цыганщины, только практические моменты.

Как приручить DDD
Константин Густов (Райффайзенбанк)

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

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

Logic Review как инструмент принятия сложных технических решений
Илья Кашлаков (Яндекс.Деньги)

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

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

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

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

Как определить приоритеты и метрики успеха при старте проекта с нуля: опыт создания лидара в Яндексе
Дмитрий Соломенцев (Яндекс)

В своём докладе я расскажу особенности разработки железа и чем она отличается от разработки софта (спойлер: она отличается). Как и какие метрики выбрать при разработке hardware проекта и покажу результат которого мы достигли при разработке такого проекта.

Проиллюстрирую доклад примером создания лидера для беспилотных автомобилей в Яндексе. Лидар — лазерный сенсор, способный воспроизводить трехмерную картину мира. Для беспилотных автомобилей лидар - основной сенсор, опираясь на который автомобиль принимает те или иные решения.

Внедрить новую технологию и не растратить все полимеры
Павел Минеев (Рокетбанк)

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

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

Как запустить MVP и не превратить его в техдолг
Максим Аршинов (Хайтек Груп)

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

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

Код действительно выкидывают, если “не взлетело”. А что делать, когда тестовый запуск прошел успешно, и в нашей поделке уже живут настоящие пользователи? Часто, несмотря на все первоначальные договоренности приходится поддерживать и развивать то, что называлось MVP, дальше.

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

To Jira or not to Jira, that is the question…
Антон Черноусов (The Art Of Programming)

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

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

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

Переходим от хаотических релизов к регулярным, или Строим качественный CI
Александр Дубровин (Superjob)

Системы непрерывной интеграции давно стали стандартом в разработке программного обеспечения и уже являются неотъемлемой частью серьезных сервисов-хостингов — travis-ci, bitbucket-pipelines, gitlab auto-devops и подобные. Но всё это инструменты, которые позволяют построить и автоматизировать процесс непрерывной интеграции, а сам факт использования этих инструментов не гарантирует наличия такого процесса в вашем проекте. Мы попробуем разобраться в самом процессе, понять, что же такое качественный ci и как с его помощью навести порядок в процессе релизов.

Проблемы и боли техлида. Как решить свои проблемы?
Евгений Корытов (NDM Systems)

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

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

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

Я дам вам фреймворк для решения ваших проблем, а не буду грузить вас “самописным решением и костылями”.

Как писать читаемый код
Григорий Петров (Evrone)

Часто, посмотрев на старый код, мы говорим: "проще переписать, чем поменять". Печальнее всего, когда это наш собственный код, с любовью написанный "всего лишь" несколько лет назад.

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

Скрытое содержимое.

TechLead Conf 2020 Онлайн-конференция

Складчина: TechLead Conf 2020 Онлайн-конференция

Вложения:

techlead2020.png