В первой статье из серии про Python Day на Positive Hack Days мы говорили о том, какие доклады ожидаются на конференции. В этой статье мы хотим поговорить о нововведениях этого года: битвах технологий и круглом столе. Битвы технологий — это короткие динамичные дискуссии, посвященные разным аспектам языка Python, которые будут проходить в течение дня на конференции. Ниже несколько слов о том, чему будут посвящены битвы, и о том, кто примет в них участие ⚔️
Битва веб‑фреймворков.
🎤 Участники: Бейлак Алиев (expert software engineer, community lead в крупном банке), Оксана Емеличева (главный инженер по разработке, Сбербанк)Мы спросили Бейлака и Оксану, чего они ждут от хорошего веб‑фреймворка для Python.
Бейлак: «Вот чего я ожидаю от хорошего веб‑фреймворка:
Простота использования — чтобы быстро начать и легко разбираться.
Асинхронность — для эффективной обработки запросов.
Типизация и статический анализ — чтобы минимизировать ошибки.
Гибкость и расширяемость — для адаптации под нужды проекта.
Документация и сообщество — для поддержки и быстрого решения проблем.
Крутизна — чтобы разработчики могли гордиться им и использовать его с удовольствием».
Оксана: «Для меня важно, чтобы фреймворком можно было легко начать пользоваться, чтобы он имел большую и подробную документацию, а также широкое комьюнити и регулярные обновления.
Хороший фреймворк должен включать в себя все необходимые «батарейки в комплекте», не требуя установки дополнительных зависимостей. Он должен быть удобным в использовании, позволять быстро писать код, а также легко его поддерживать и масштабировать.
Но на самом деле, самое главное — это чтобы фреймворк удовлетворял всем задачам проекта и вашим потребностям».
В каких именно фреймворках участники битвы находят то, что им нужно, — вы узнаете на конференции. Может быть, вы знаете те, которые подходят под описанные критерии? Пишите свои варианты в комментариях к статье!
Битва DI‑фреймворков.
🎤 Участники: Александр Ковалев (руководитель группы разработки, IVA Technologies), Георгий Бородин (тимлид кроссфункциональной команды, «Литрес»)
Спикеров этой битвы мы также спросили о том, чего они ожидают от хорошего DI-фреймворка.
Александр: «Важно, чтобы фреймворк не усложнял понимание кода, не заставлял писать сильно больше кода, чем без него. Чем меньше декораторов и аннотаций, тем лучше. Все зависимости должны быть легко прослеживаемыми. Магия — это весело, пока не приходится дебажить. Если фреймворк заставляет меня писать код так, как будто это Java или C#, — это повод насторожиться. DI в Python должен оставаться питонячьим».
Георгий: «Важнее всего — человеческий интерфейс и минимальное количество бойлерплейта. Идеально — когда фреймворк уже из коробки имеет рецепты для популярных веб- и прочих фреймворков, но иногда лучшее — враг хорошего. Ну и, конечно, фреймворки — это хорошо, но умелые руки всегда смогут собрать сервис-локатор :)».
На конференции мы узнаем, какие DI-фреймворки участники битвы видят подходящими для себя, ну а вы можете высказать свое мнение в комментариях.
Битва архитектурных подходов.
🎤 Участники: Максим Столпасов (тимлид бэкенда, X5 Tech), Михаил Гурбанов (тимлид в крупном банке)
Мы спросили участников, что главное в архитектурном подходе, и вот что они нам сказали:
Максим: «В архитектурном подходе для меня главное — это системность. Любая архитектура — это про то, как разделять и властвовать, но также важно и то, как эти разделенные части взаимодействуют между собой на уровне кода, как команды этих частей взаимодействуют между собой и с бизнесом и насколько они решают задачи бизнеса и предметной области».
Михаил: «На мой взгляд, в архитектуре важно, чтобы подход к ней был понятен без лишнего контекста. Хорошо, когда в нее можно быстро вникнуть, не разбираясь в тоннах внутренней логики или истории проекта. Чем проще и прозрачнее архитектура — тем легче разработчику включиться в работу.
Простота также снижает вероятность случайных багов и упрощает ревью: когда код читается и не вызывает лишних вопросов, легче заметить, если что‑то идет не так.
При этом, конечно, архитектура должна быть масштабируемой и соответствовать задачам продукта. Но усложнять стоит только тогда, когда это действительно нужно. В остальных случаях — чем проще, тем быстрее можно двигаться и приносить результат.
Чистота, ясность и практичность — вот признаки архитектуры, которая хороша для любого проекта».
Согласны? Милости просим в комментарии!
И наконец, завершит конференционный день круглый стол про InnerSource (использование подходов open source внутри корпоративных границ).
🎙️ Участники круглого стола: Денис Аникин (community lead в крупном банке), Николай Хитров (техлид, «Точка»), Анастасия Олеск (тимлид разработки, X5 Tech)
Мы спросили участников круглого стола, зачем, по их мнению, использовать InnerSource в компаниях.
Денис: «Иннерсорс принято перехайпливать и недооценивать. Его воспринимают как решение всех проблем и сразу. Стоит сказать сверху „иннерсорс“ — и все проблемы решены. На деле, конечно, все не так радужно. Иннерсорс‑решения далеко не всегда хорошие и далеко не всегда помогают решать проблемы. Иногда иннерсорс — это NIH‑синдром в чистом виде. А иногда это скорее вера менеджмента, чем что‑то полезное. Тимлиды и руководители выше обожают друг другу продавать и рекламировать этот подход. А когда ты приходишь к обычным разработчикам, часто можно узнать, чего стоит местный иннерсорс и как приходится с ним жить.
Иннерсорс — это полезный подход, с которым нужно системно работать, выделяя энтузиастов в компании. Он может помочь решить некоторые системные проблемы, но также может их и создать. Поэтому важно помнить, что однажды начав делать иннерсорс, вы будете нести бремя его поддержки и развития. Если вы к этому не готовы, а в компании нет энтузиастов — лучше пойти в иннерсорс попозже, когда они появится».
Анастасия: «Зачем компаниям использовать Innersource? Чтобы девопсы, разработчики и тимлиды меньше плакали от многообразия подходов и граблей в каждой команде. Чтобы больше никто не сталкивался с ситуацией, когда ты принимаешь проект, а тебе скидывают.py‑файл на 10 000 строк и говорят: „Git? Нет, не слышали...“ Чтобы не стоять в очередях на интеграцию и чтобы взаимодействие со смежными командами перестало быть лотереей».
А о том, как именно используются практики InnerSource в компаниях спикеров, вы сможете узнать на конференции.
✅ Напоминаем, что Python Day состоится 24 мая, однако мы предлагаем запланировать посещение Positive Hack Days на все дни, с 22 по 24 мая: на фестивале будет много интересных активностей. Посетить Python Day и все другие треки Киберхаба вы можете по единому билету, который действует во все дни.
До встречи на PHDays Fest!
