🌟 Код-ревью — это проверка кода, написанного разработчиком для решения задачи, перед вливанием в основную ветку проекта.

✅Почему это полезно?

👉 Прокачивает навыки — вы учитесь на реальных примерах, а не на своих ошибках.

👉 Ускоряет рост — без код-ревью можно годами оставаться на одном уровне.

👉 Заставляет анализировать свой опыт. Если вы сами делаете код-ревью и объясняете, почему предложенное вами решение будет лучше.


Разбираем пользу код-ревью в нашей статье. Читайте и делитесь впечатлениями в комментариях!

Кофеин, стресс и бесконечные митинги: жизнь настоящего проджекта

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

Важно, что менеджеров в IT, около IT и вообще, много. Сегодня мы говорим именно про менеджеров проектов, не про продуктовых, операционных, аккаунт, бренд или каких-то ещё. Если будет интересно, в следующих постах поговорим и о других.

Сегодня Артем Каменев, ПМ с опытом 5+ лет поделится с нами своим опытом. Начнём сразу с самого больного вопроса.

❓Почему программисты ненавидят PM-ов?
Чаще всего, потому что не знают или не понимают, для чего они нужны.

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

❓Что делает PM?
✏️Следит за соблюдением планов и договоренностей;
✏️Отчитывается перед руководством компании о расходах и сроках проекта;
✏️Демонстрирует прогресс для заказчиков, неважно внешние они или внутренние;
✏️Собирает обратную связь по проекту со всех заинтересованных.

❓Как он это делает?
✏️Ведёт задачи в таск-трекере и следит за тем, чтобы другие вели их правильно;
✏️Проводит регулярные и точечные встречи с командой и заказчиком;
✏️Отслеживает трудозатраты и расходы по проекту;
✏️Заполняет отчёты и ведёт статусные страницы в вики-подобном формате;
✏️Переписывается. Постоянно и без остановок.

❓Какие бывают подходы к управлению проектами?

Подходов и фреймворков для ведения проектов много. Однако, их можно разделить на 3 категории:

👉 Каскадный (waterfall) подход. В IT чаще всего встречается в небольших проектах (1-3 месяца) и при работе с гос. организациями.

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

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

👉Гибкий (AGILE) подход — встречается повсеместно и постоянно, т.к. гибкость понятие очень широкое :)

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

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

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

👉 Гибридный подход — берём лучшее из каскадного и гибкого подходов, смешиваем и наслаждаемся.

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

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

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

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

➡️ Какой у вас опыт работы с ПМ-ами? Кто был наихудший, а кто наилучший и почему? И присылайте ваши любимые мемы про проджектов в комменты!

Чем UV лучше pip

❓Что такое UV

UV — это современный инструмент управления зависимостями и сборки Python-проектов. Он предоставляет удобный способ работы с зависимостями, используя стандартный файл pyproject.toml, и обеспечивает более строгий контроль версий, что делает проекты более предсказуемыми и стабильными.

👉Альтернативы
– Pip
– Poetry

✅Почему стоит выбрать UV
— Удобство. UV использует единый файл pyproject.toml для управления зависимостями и конфигурации проекта.
— Совместимость. UV поддерживает PEP 517 и PEP 518, что делает его совместимым с большинством современных инструментов Python.
— Быстрота. UV оптимизирован для быстрого разрешения зависимостей.
— Безопасность. UV предоставляет возможность блокировки зависимостей, что предотвращает неожиданные изменения в версиях библиотек.
— Функциональность. UV предоставляет возможность управления версиями Python в системе, а также автоматическое управление виртуальными окружениями.
— Универсальность. UV имеет одинаковый интерфейс для работы на различных системах, что позволяет одинаково использовать на Windows, MacOS и Linux.

❌ Какие минусы есть у UV
— Новая экосистема. Для пользователей, привыкших к pip, потребуется время на изучение UV.
— Ограниченная поддержка старых проектов. Некоторые старые проекты могут не поддерживать pyproject.toml.
— Меньшая популярность. UV пока менее распространён, чем pip, что может затруднить поиск решений для специфических проблем.

🛠 Установка uv
Актуальные способы установки UV в вашу систему можно найти в официальной документации.

🔧 Интеграция UV в уже существующий проект
Для интеграции UV в проект есть два пути:
📎 Полный переход на UV
📎 Переход на UV с использованием совместимого интерфейса pip

Подробно об интеграции UV рассказали 👉 здесь

Наш преподаватель и Senior QA Tools инженер Артем поделился своим опытом использования UV:

Ребята из команды Astral решили серьёзно заняться экосистемой Python и запилили тулу, которая призвана заменить pip. Тула написана на Rust, придерживается всех PEP'ов и резолвит зависимости в 10-50 раз быстрее pip.

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

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

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

⚡️Вывод: Сегодня pip в Python-сообществе — стандарт, и его популярность отражает широкое использование Python во многих областях, таких как анализ данных, машинное обучение, веб-разработка и многое другое.

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

💥На майских праздниках мы провели интенсив по проектированию баз данных!

🔥 Было жарко! На интенсиве каждый из участников общался индивидуально с Евгением. Обсудили:
— как спроектировать БД, чтобы не переделывать 100500 раз,
— как учесть не только текущие требования, но и точки расширения,
— рассмотрели кейсы, чему не место в базе.

Делимся отзывами участников об интенсиве:

Интенсив понравился, Евгений все объяснял доходчиво, формат зашел. Рекомендовал бы тем, кто уже делает проекты на Django, но кому не хватает опыта проектирования более серьезных баз данных.

Я прошла интенсив по проектированию баз данных у Евгения Евсеева. Мой уровень — завершила модуль «От джуна до мидла», впереди стажировка.

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

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

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

Интенсив оказался интересным и полезным, хоть и немного не таким, как я представлял. Посоветовал бы, сделать более четкую структуру подачи материала и больше проработать задания, чтобы они были менее «импровизационными». Хотя формат «Заказчик, как в жизни» все равно получился интересным!

Объяснения Евгения были понятными и по делу, получил ответы на все вопросы, которые возникали во время прохождения. В целом — опыт полезный и интенсив понравился, но есть куда расти!

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

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

Единственное, чего не хватило — времени. Было бы круто, если бы на самостоятельную работу его было бы больше.

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

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

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

В целом, очень интересный опыт, считаю, что он будет очень полезен в работе!

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

✅ Обратную связь и пожелания по новому формату учтем при запуске следующих групп!

🔥А еще скоро мы начнем делиться инсайтами с интенсива! Не пропустите!

Собеседование — важный этап поиска работы мечты. К нему можно и нужно готовиться. Благодаря подготовке, у вас будут не только готовые ответы на типовые вопросы, но и меньше волнения!

Сегодня разберем один из вопросов, который часто задают работодатели на собеседованиях веб-разработчиков на Python!

❓Что происходит под капотом джойна? Какие есть алгоритмы соединения таблиц?

В реляционных базах данных, таких как SQL, операцию соединения (join) используют для объединения строк из двух или более таблиц, основываясь на связанных между
ними столбцах. Есть разные типы алгоритмов соединения, каждый из которых имеет свои преимуществ и подходит для разных сценариев.

Разберем основные типы:

📎Nested Loops Join (Циклическое соединение)

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

⚙️Когда использовать: Эффективен, когда одна из таблиц значительно меньше другой. Обычно применяют, когда нет индексов, которые можно использовать для
оптимизации запроса.

❌ Недостатки: Может быть медленным, особенно если обе таблицы большие, так как требует многократного перебора строк.

📎Hash Join (Хеш-соединение)

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

⚙️Когда использовать: Хорошо подходит для больших таблиц, особенно когда соединение не может быть оптимизировано с помощью индексов. Эффективен для соединений типа equi-join (способ объединения данных из двух таблиц по равенству значений в указанных столбцах).

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

📎 Merge Join (Слияние)

👉 Как работает: Сначала сортирует обе таблицы по столбцам соединения, а затем итеративно проходит через обе таблицы одновременно для поиска совпадений.

⚙️Когда использовать: Особенно эффективен, если обе таблицы уже отсортированы по соответствующим столбцам. Часто используется для соединений с диапазоном условий.

❌ Недостатки: Может быть медленным, если таблицы не отсортированы, так как требует предварительной сортировки.

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

Современные системы управления базами данных (СУБД) часто автоматически выбирают оптимальный метод соединения на основе этих факторов.

👉Пишите вопросы с собеседований, которые хотели бы разобрать, в комментариях!

#вопросы_с_собесов

🤔 Давайте вместе разберемся, что не так с этим кодом?

capitals = ('Москва', 'Лондон', 'Париж')

for i in capitals:
  ...

👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана.

Вместо абстрактной буквы i удобнее работать с конкретным, именованным объектом. Название должно быть содержательным, должно соответствовать объекту, описывать его.

❌Использование абстрактных символов и букв в программировании — плохая практика и вот почему:

— Снижается читаемость
Когда голова забита кодом, вы вскоре уже сами не вспомните, что значит i (особенно, если таких букв не одна). Придется тратить время на расшифровку. Другие разработчики, особенно джуны, будут дольше разбираться в вашем коде.

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

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

✅ Переменную в нашем примере стоит назвать так:

capitals = ('Москва', 'Лондон', 'Париж')

for capital in capitals:
  ...

В современном мире обучение и развитие — ключевые факторы успеха. Но кто должен инвестировать в знания сотрудников?

Множество компаний включают оплату обучения в соцпакет — и это не просто жест доброй воли, а продуманная HR-стратегия. По данным исследования 47% работодателей в 2024 году оплачивали курсы повышения квалификации своим сотрудникам (правда не всем).

❓Зачем это работодателю

— Повышение квалификации команды
Сотрудники осваивают быстро меняющиеся технологии, работают быстрее и качественнее.

— Меньше текучки кадров
Сотрудники чувствуют свою ценность, потому что компания готова вкладываться в их развитие. А некоторые работодатели оплачивают обучение с обязательством отработать N лет, иначе нужно вернуть деньги.

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

— Укрепление репутации компании
Возможность бесплатно учиться делает компанию более привлекательной для топ-спецов.

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

🚀 А для сотрудников — это возможность бесплатно прокачать свои скиллы и построить карьеру!

🔥В Devman есть возможность оплатить обучение через работодателя — как «Профессию Middle Python/Django разработчик», так и мини-курсы!

Для проведения оплаты через работодателя напишите нам в Телеграм

🔥Делимся материалами с майского интенсива по проектированию баз данных!

👉Рассказываем:
— О важности тестирования требований заказчика. Почему важно НЕ брать в работу все, о чем говорит заказчик?
— Что такое референсы и почему они важны в разработке БД.
— Почему важно учитывать ограничение технологий

🌟Видео можно посмотреть на всех популярных видео-площадках:
Ютуб
Рутуб
VK Видео

Подписывайтесь! Впереди еще много интересного!

Django — один из самых мощных и популярных Python-фреймворков для веб-разработки. Его используют крупные компании, стартапы и open-source проекты благодаря безопасности, масштабируемости и богатой экосистеме.

10+ известных проектов на Django

1️⃣ Instagram*

Один из крупнейших проектов на Django (хотя сейчас частично переписан на другие технологии). Использовал Django для быстрого старта и масштабирования.

2️⃣ Pinterest
Начинал с Django, но позже перешёл на другие решения для API. Использует Django ORM и шаблонизацию.

3️⃣ Spotify
Внутренние инструменты и аналитика работают на Django. Использует Django REST Framework (DRF) для API.

4️⃣ Disqus
Крупнейшая система комментариев в интернете. Обрабатывает миллиарды запросов с помощью Django + PostgreSQL.

5️⃣ The Washington Post
Один из крупнейших новостных сайтов. Использует Django для управления контентом (CMS).

6️⃣ NASA (некоторые проекты)
Внутренние веб-приложения для анализа данных. Например, сайт "Climate Change NASA" частично работает на Django.

7️⃣ Mozilla Firefox (Support Site)
Сайт поддержки Firefox (support.mozilla.org) написан на Django.

8️⃣ Bitbucket (до перехода на React + DRF)
Git-хостинг от Atlassian изначально использовал Django.

9️⃣ Eventbrite
Платформа для продажи билетов на мероприятия. Начинала с Django, но сейчас использует микросервисы.

🔟 Prezi
Онлайн-редактор презентаций. Бэкенд частично работает на Django.

1️⃣1️⃣ Robinhood (бэкенд-сервисы)
Финтех-стартап использует Django для некоторых внутренних API.

1️⃣2️⃣ Udemy (часть бэкенда)
Платформа онлайн-курсов использует Django + DRF.

1️⃣3️⃣ The Onion (сатирические новости)
Весь контент-менеджмент работает на Django.

1️⃣4️⃣ Lichess (шахматы онлайн)
Open-source шахматная платформа с Django-бэкендом.

1️⃣5️⃣ Django CMS
Популярная система управления контентом, построенная на Django.

✅ Почему выбирают Django?
— Безопасность — защита от OWASP Top 10 из коробки.
— Админка — Django Admin — готовая панель управления.
— ORM — удобная работа с БД без SQL.
— Масштабируемость — Instagram* и Disqus доказали, что Django справляется с высокой нагрузкой.

Django — отличный выбор для сложных веб-приложений, CMS, маркетплейсов и соцсетей. 🚀

Познакомиться с Django можно на наших курсах:
👉 «Профессия Middle Python/Django разработчик» и стажировка на проектах с Django
👉 Мини-курс Django: ORM
👉 Мини-курс Django

*деятельность организации Meta Platforms Inc и ее продуктов Instagram и Facebook запрещена в Российской Федерации.

Фундамент вашего проекта: как проектирование БД сэкономит вам время или убьёт ваш код

Представьте, что вы строите небоскреб и после 20 этажа понимаете, что при возведения следующего этажа фундамент не выдержит. Можно ли выдернуть фундамент из-под небоскреба и заменить его или проще все снести и построить заново?

Тоже самое и с базами данных в разработке.

Когда можно не проектировать БД заранее?

Бывают ситуации, когда проектирование базы данных, как отдельный этап разработки не оправдано. Это случаи, когда проще сделать, потом понять, что получилось не очень и переделать. Например, при прототипировании или, если вы делаете экспресс разработку MVP «на выброс».

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

❌Что будет, если не уделить должного внимания проектированию:
— Тяжело делать запросы к БД
— Тяжело обновлять данные так, чтобы они оставались согласованными. Дата-миграции замучают команду и сорвут сроки разработки.
— Невозможно добавить новый функционал без изменения в моделях данных. А это часто влечет за собой переписывание всего кода или большей его части!

✅Как этого избежать

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

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

👉 А вы сталкивались с проблемами из-за проектирования базы данных? Делитесь опытом в комментариях!