Яндекс Практикум. Программирование и анализ данных

Культура работы с Git: пуллреквест — о чём спросить команду, часть 2 ❓ Спросите об этом заранее — это даст вам максимум контекста и поможет быстрее освоиться в команде и процессах. 🎯Какая автоматизация настроена в ветке на разные события (новый коммит, мерж изменений)? Эту информацию вы можете получить и сами, например, детальнее рассмотрев блок Checks в интерфейсе GitHub (аналогичные есть и других сервисов, например у GitLab или Bitbucket), либо заглянув в файлы автоматизации, если они хранятся в вашем репозитории. Например, это будет файл с названием .gitlab-ci.yaml, либо yaml файлы в директории .github — читайте подробнее по ссылкам. Если сложно ориентироваться в файлах, или они хранятся не в рабочем репозитории, уточните, какие проверки являются обязательными. Часто в проектах автоматизация настроена так, что пуллреквест нельзя замержить, если не прошли линтеры и тесты. 🎯Как и куда выкладываются изменения, когда ветка замержена, на какое окружение? Иногда публикация изменений может быть автоматизирована. Когда вы пушите новый коммит или мержите ветку, на какое-то окружение (например, dev или staging) выкладываются изменения, чтобы уйти на проверку QA инженеру. Уточните, нужно ли нажимать Deploy вручную или выполнить какие-то команды, чтобы внести изменения. 🔖Сохраняйте себе, пишите вопросы и делитесь мыслями в комментариях. Автор поста Юлия Волкова обязательно придёт их почитать и ответить!

Культура работы с Git: пуллреквест — о чём спросить команду ❓ Начнём с более формальных вещей — они касаются пока не самого код-ревью, а работы в пуллреквесте в целом. Вот список вопросов, который поможет познакомиться с основными процессами работы с пуллреквестами в новой команде. 🎯В какую базовую ветку (base branch) делать пуллреквест? Уточните, потому что далеко не всегда это main (master). Зависит от того, как построен процесс работы с ветками в вашей команде: это может быть, например, ветка develop или release. Про подходы к организации веток я подготовлю отдельный пост. 🎯Кого ставить в ревьюеры? Иногда это почти вся команда, а иногда конкретный человек, например, тим- или техлид. 🎯Сколько аппрувов получить, прежде чем замержить ветку? Стоит спросить, потому что не всегда это ограничение автоматизировано в репозитории. 🎯Есть ли какие-то соглашения по именованию веток и коммитов? О цели и возможной пользе разных подходов мы подробно говорили ранее в этом посте. 🎯Нужно ли сквошить (squash) коммиты? Некоторые команды в конце работы над пуллреквестом обязательно объединяют все изменения в один коммит — так проще ориентироваться в истории. 🎯Что использовать — merge или rebase? Одни команды не накладывают ограничений, другие выбирают тот или иной способ. У каждого подхода есть плюсы и минусы, подробнее об этом рассказывают в статье на Хабре. Если в вашей команде есть соглашение использовать именно git rebase, то рекомендую статью Как ребейзить ветку и не думать ни о чём, чтобы лучше разобраться в алгоритме действий. ⤵️ Впереди вторая часть и ещё несколько важных вопросов.

Культура работы с Git: пуллреквест — о чём спросить команду, часть 2 ❓ Спросите об этом заранее — это даст вам максимум контекста и поможет быстрее освоиться в команде и процессах. 🎯Какая автоматизация настроена в ветке на разные события (новый коммит, мерж изменений)? Эту информацию вы можете получить и сами, например, детальнее рассмотрев блок Checks в интерфейсе GitHub (аналогичные есть и других сервисов, например у GitLab или Bitbucket), либо заглянув в файлы автоматизации, если они хранятся в вашем репозитории. Например, это будет файл с названием .gitlab-ci.yaml, либо yaml файлы в директории .github — читайте подробнее по ссылкам. Если сложно ориентироваться в файлах, или они хранятся не в рабочем репозитории, уточните, какие проверки являются обязательными. Часто в проектах автоматизация настроена так, что пуллреквест нельзя замержить, если не прошли линтеры и тесты. 🎯Как и куда выкладываются изменения, когда ветка замержена, на какое окружение? Иногда публикация изменений может быть автоматизирована. Когда вы пушите новый коммит или мержите ветку, на какое-то окружение (например, dev или staging) выкладываются изменения, чтобы уйти на проверку QA инженеру. Уточните, нужно ли нажимать Deploy вручную или выполнить какие-то команды, чтобы внести изменения. 🔖Сохраняйте себе, пишите вопросы и делитесь мыслями в комментариях. Автор поста Юлия Волкова обязательно придёт их почитать и ответить!

Культура работы с Git: код-ревью и пуллреквесты Продолжаем серию статей «Культура работы с Git» от Юлии Волковой. В предыдущих постах рассказали про именование веток и о правильных сообщениях к коммитам. Код-ревью — один из важнейших аспектов работы с Git. Это не только про код, это ещё и про взаимодействие внутри команды. Речь не только о том, чтобы отлавливать баги или спорить о стайлгайдах. Если подойти к процессу осознанно, он принесёт команде и каждому участнику очень много пользы. Код-ревью помогает: 🎯быть в курсе контекста по разным задачам в проекте; 🎯совместно принимать решения: от стайлгайдов и выбора библиотек до архитектуры; 🎯улучшать качество кода и вырабатывать более оптимальные решения; 🎯ещё на этапе разработки нового функционала оценить масштабируемость, поддерживаемость решения, учесть возможные риски и corner cases; 🎯обратить внимание на необходимость переиспользования каких-то компонентов или утилит; 🎯быстрее знакомить новых сотрудников с проектом; 🎯обучаться и улучшать свои навыки - как хард-скиллы, так и софт-скиллы. Как видите, код-ревью — это ещё и про коммуникацию, общение и взаимодействие внутри команды. А ещё про ценности: например, обмен знаниями, обучение, взаимопомощь, стремление сделать лучше. 🔖Посмотрите небольшой доклад «Код-ревью с уважением» Ангелины Купцовой с митапа SPB Frontend, чтобы узнать о теме больше. И советую почитать статью «Что такое код-ревью» от Доки. ⤵️ В следующих постах я поделюсь рекомендациями, которые помогут сделать работу в пуллреквесте и ревью немного более полезным и комфортным.

Культура работы с Git: пуллреквест — о чём спросить команду ❓ Начнём с более формальных вещей — они касаются пока не самого код-ревью, а работы в пуллреквесте в целом. Вот список вопросов, который поможет познакомиться с основными процессами работы с пуллреквестами в новой команде. 🎯В какую базовую ветку (base branch) делать пуллреквест? Уточните, потому что далеко не всегда это main (master). Зависит от того, как построен процесс работы с ветками в вашей команде: это может быть, например, ветка develop или release. Про подходы к организации веток я подготовлю отдельный пост. 🎯Кого ставить в ревьюеры? Иногда это почти вся команда, а иногда конкретный человек, например, тим- или техлид. 🎯Сколько аппрувов получить, прежде чем замержить ветку? Стоит спросить, потому что не всегда это ограничение автоматизировано в репозитории. 🎯Есть ли какие-то соглашения по именованию веток и коммитов? О цели и возможной пользе разных подходов мы подробно говорили ранее в этом посте. 🎯Нужно ли сквошить (squash) коммиты? Некоторые команды в конце работы над пуллреквестом обязательно объединяют все изменения в один коммит — так проще ориентироваться в истории. 🎯Что использовать — merge или rebase? Одни команды не накладывают ограничений, другие выбирают тот или иной способ. У каждого подхода есть плюсы и минусы, подробнее об этом рассказывают в статье на Хабре. Если в вашей команде есть соглашение использовать именно git rebase, то рекомендую статью Как ребейзить ветку и не думать ни о чём, чтобы лучше разобраться в алгоритме действий. ⤵️ Впереди вторая часть и ещё несколько важных вопросов.

Чем заняться на долгих выходных⭐ Послушать «Что дальше?» — подкаст о том, как перепридумать себя. Из маркетолога в музыканты, из журналистки в тренеры AI — наши герои превращают хобби в источник дохода и осваивают профессии, которых не было ещё пару лет назад. Вместе со студией «Норм» рассказываем, как совершить карьерный поворот в любом возрасте и с любым опытом: сколько это стоит, какие есть подводные камни, где искать вдохновение и силы. 🎧Слушать подкаст

Нейросеть помогает разработчикам находить ответы на вопросы по коду и объяснения по алгоритмам и структурам данных. Мы запустили курс «YandexGPT для начинающих» — вы научитесь использовать нейросети, чтобы автоматизировать рутинные задачи: ✔️Составлять запросы к YandexGPT так, чтобы с её помощью решать рабочие задачи: ✔️Генерировать необходимый контент с помощью нейросетей ✔️Создавать графический контент в Шедевруме ✔️Учитывать ограничения ИИ-моделей ✔️Разбираться, как использовать технологии безопасно и этично ✔️Понимать, как использовать возможности нейросетей в своей работе Курс бесплатный, программа рассчитана ≈ на 2 часа. Её составили опытные специалисты Яндекса, которые применяют в своей работе YandexGPT и YandexART. Разработчики нейросетей участвовали в создании курса, поэтому вы из первых уст узнаете обо всех алгоритмах и ограничениях. На протяжении курса вы будете работать над учебным проектом, который сможете добавить в портфолио. Узнать больше про курс и начать учиться →

Друзья, приходите на курс «Алгоритмы и структуры данных»!

В 14:00 подключайтесь к эфиру «Алгоритмы на собеседованиях: нужны ли они?» в этом канале и задавайте ваши вопросы в комментариях ✨

Вокруг этого ходит много споров, кто-то даже негодует, что алгоритмы спрашивают при трудоустройстве. Спорить мы не будем, а будем разбираться, как с этими совладать. 15 февраля в 14:00 в этом канале мы проведём прямой эфир, где разберёмся, в чём польза алгоритмов и решим вместе задачи, которые мы публиковали в канале, а ещё обсудим: ✨ с чего начать изучение новичку; ✨ стоит ли учить алгоритмы с помощью паттернов; ✨ к чему быть готовым на алгоритмической секции собеседования. Гость эфира: Фёдор Мушенок — наставник в Практикуме в направлении анализа данных. Подключиться к эфиру можно по ссылке. Если у вас есть вопросы, обязательно пишите их в комментарии и приходите на эфир, мы ответим на них ✨

Решаем алгоритмические задачи — 2 ✔ Давайте попробуем задачку посложнее.

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

Если разберётесь — оставляйте ответ в комментариях!

Решаем алгоритмические задачи ✔

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

Предлагайте свои варианты в комментарии — посмотрим, насколько вы сильны в алгоритмах!

Культура работы с Git: именование веток Это продолжение серии статей «Культура работы с Git» — в прошлый раз мы говорили о правильных сообщениях к коммитам. В этот раз обсудим именование веток: зачем вообще это нужно и каким рекомендациям следовать, чтобы команде было приятно и легко работать. → Читать статью

Друзья, чтобы научиться использовать Git для совместной работы над проектами, можно пройти курс «Основы работы с Git» — он бесплатный!

Git: вопросы для самопроверки Вы просили — мы сделали: Юлия Волкова — фронтенд-разработчик и наставник на курсе «React-разработчик» — вернулась с новой порцией полезного про Git. Ей слово. Давайте проверим, знаете ли вы основные команды, практики, которые вокруг них существуют, и алгоритмы решения типовых ситуаций. Насколько уверенно вы можете ответить на следующие вопросы: ❓Почему стоит почти всегда начинать свою работу с команды git pull, если вы не forever alone на проекте? ❓Почему стоит пользоваться командой git push почаще (хотя бы раз в день)? Какие риски могут быть, если вы редко отправляете изменения в удалённый репозиторий? ❓Представьте, что вы сделали пуллреквест, отправили его на ревью. Ревьюер предложил вам мелкую правку прямо в ПР (например, поправил опечатку в слове) и вы нажали в интерфейсе Github кнопку "Commit changes". После нажатия на эту кнопку изменения попадут вам сразу и в локальный репозиторий? ❓Какие основные практики оформления коммитов вы знаете? ❓Зачем нужно ветвление в git? ❓Вы сделали коммит, отправили изменения в удалённый репозиторий. И тут в интерфейсе Github вдруг видите, что приехало не всё, над чем вы работали, точно должны были быть ещё какие-то файлы. Что пошло не так и как это исправить? ❓В вашей ветке есть конфликты с base branch. Как их разрешить? ❓Вы и коллега работали в разных ветках над разными фичами, но эти фичи могли затрагивать одни и те же файлы. Вы оба сделали ПР, но коллега замержил свой ПР быстрее, чем вы свой. В вашей ветке возникли конфликты. Вы их порешали, пересобрали свою ветку, чтобы проверить, что все ок, и при проверке понимаете, что что-то поломалось. Что-то отвалилось в том, над чем работали вы и/или пропали какие-то части изменений, которые вносил коллега. Как всё исправить, чтобы в вашей ветке корректно работало то, над чем трудились вы, и были видны все изменения коллеги? Оставьте в комментариях цифры от 0️⃣до 8️⃣ — по количеству вопросов/ситуаций, с которыми справились. Если будет нужно, разберёмся в нюансах вместе)