Тимлид Леонид

Встречи наши встречи 💬  Принесли вам бинго типичного созвона — напишите в комментариях, если мы что-то забыли.

🐞 Fun fact: слово «баг» буквально означает «жук» И это не совпадение! Термин bug («жук») инженеры использовали ещё задолго до появления современных компьютеров — так они называли любые неполадки в работе техники. Но настоящую популярность слово получило в 1947 году. Инженер и пионер программирования Грейс Хоппер с коллегами искала причину сбоя компьютера Mark II и обнаружила настоящую бабочку, застрявшую между контактами реле. Насекомое приклеили в журнал неисправностей с подписью: «Первый случай, когда был найден настоящий баг». С тех пор слово «баг» прочно вошло в обиход 😉

А вы знаете, почему ошибки в коде называют багами? 🐞 🔥 — Да, знаю 🤔 — Не-а, просветите меня

Привет! Меня зовут Виталий Панаит, я разработчик в Skyeng. В прошлой статье я рассказывал про систему, которая автоматически собирает и сохраняет контекст проекта. И пока мы строили этот «второй мозг» команды, стало понятно, что похожая проблема есть ещё в одном месте — в код-ревью. Сам процесс ревью у нас был выстроен давно, но чем больше становилось задач и команд, тем заметнее было, что результат начинает зависеть от человеческого фактора. Всё по классике: у кого-то горят сроки, кто-то переключается между пятью задачами одновременно. Тогда мы начали думать, можно ли часть этой рутины отдать ИИ. 🔗 Статья о том, как мы встроили ИИ в ревью кода и разгрузили разработчиков

Ожидание: дежурный мощными лапами разгребает все влёты 🐺 Реальность: был в сети 15 минут назад 🕘 Уже рассказывали, как наша система дежурств спасает команду от хаоса и расфокуса. Но когда мы только внедряли эту практику, время от времени что-то давало сбой: – терялась информация при передаче смены; – всё дежурство сводилось к поискам ответственных и тегам других разработчиков; – в первые итерации дежурные только тушили пожары, поэтому появился страх, что так будет всегда, а с ним — мандраж и выгорание. Как мы научились этого избегать? Пришлось кое-что поменять в процессах. ➡️ Готовимся к дежурству Сначала проверяем, что у дежурного есть все доступы (k8s, актуальная БД, деплой), чтобы решать проблемы самому, а не бегать по личкам. Выкручиваем уведомления на максимум (в десктопе и в мобилке), чистим календарь от неважных встреч, а бэклог — от больших задач, где нужно погружение. Ставим в статус 👷‍♂️ и начинаем дежурство. Реакции в каналах тоже должны быть прозрачными: • 👀 — увидели алерт; • 🚧 — взяли в работу; • ✔️ — готово, завершено. Весь контекст и результаты фиксируются прямо в тредах или в комментариях Sentry. Если баг сложно поправить прямо сейчас, но в целом он не критичный, или дежурный занят чем-то другим, — заводим отдельную задачу. ➡️ Адекватная эскалация Обращаемся к экспертам команды, только если зашли в тупик или если понятно, что автор кода исправит всё за пять минут, а дежурный убьёт на это часы. Иногда поток фокусов аномальный: всплывает алерт, дежурный правит баг, а тут ещё поддержка что-то эскалирует. В таких случаях просим помощи у команды — один занимается багом, другой отвечает поддержке. Важно не геройствовать: зашёл в тупик — созваниваемся, шарим экран и решаем проблему вместе. Иначе никто ничему не учится, и bus-фактор так и остаётся низким. ➡️ Бесшовная передача дел Каждый дейлик начинается с вопроса «что было на дежурстве». В день пересменки уходящий дежурный передаёт незавершённые дела «из рук в руки». Если что-то потерялось, артефакты всё равно останутся в каналах — пропустить задачу не получится. Начатые дела, которые можно сделать самостоятельно, доделываем сами. ➡️ План Б на случай форс-мажора Чтобы дежурный мог заболеть, уйти на обед или в дэй-офф, а прод не сгорел в его отсутствие, заранее договариваемся с замещающим. Как правило, это следующий по графику смен дежурный. Пришли к такому регламенту методом проб и ошибок. Пока всё (тьфу-тьфу) работает. Если у вас другая схема, расскажите в комментариях 👇🏼

Тоже понравилось работать четыре дня в неделю? 💔 Следующая такая возможность будет только через месяц, из-за выходного 12 июня. А ведь какие-то счастливые люди работают в таком режиме постоянно… или несчастливые? Например, американский финтех Bolt недавно перешёл обратно на пятидневную рабочую неделю. По словам CEO, компания не смогла перестроиться. Сотрудники просто работали на износ, пытаясь уместить 40 часов задач в четыре рабочих дня, и быстро выгорали. Вы как, хотите четырёхдневку или ничего не успеваете? 👀 ❤️ — хочу так работать каждую неделю 👍 — можно иногда для разнообразия, но не всё время

🤔 «Подождите, а мы это уже обсуждали?» Та самая фраза, после которой проект начинает идти по второму кругу. Решения теряются, обсуждения повторяются, у каждого своя версия происходящего. Мы в Skyeng столкнулись с этим и собрали систему, в которой проект сам сохраняет контекст: встречи превращаются в понятные договорённости, задачи не теряются, а нужную информацию можно получить в любой момент. По сути, это «память» проекта, которая всегда под рукой 🧠 👉 Как устроена система и что она меняет в работе команды — разобрали в статье.

А-а-а, всё сломалось, ничего не работает 😭 Сказали бы мы, если бы не было дежурных разработчиков! Без них в чате с алертами всплывает уведомление, но кто-то на встрече, кто-то в потоке, а у кого-то срабатывает эффект свидетеля: «Это не мой код, пусть посмотрит кто-то другой». В итоге получаем целый букет проблем: ➡️ реакция с задержкой; ➡️ расфокус команды, которую постоянно дёргают; ➡️ низкий bus factor и др. Как дежурство помогает это решить Дежурный разработчик — щит команды. Пока остальные ребята спокойно пилят задачи, он сфокусирован на немедленном реагировании. Главное правило: дежурный отвечает в первую очередь за дежурные обязанности. Другие задачи второстепенны. Тогда у человека появляется ресурс «лечить болезнь», а не исправлять «симптомы» с помощью костылей. Как выбирают дежурных и что они делают Дежурят только бэкэнд- и фулстек-разработчики. Смена длится ровно неделю — эстафету передаём по пятницам на дейли (график составляем заранее на квартал, учитывая отпуска и баланс нагрузки). Во время дежурства двигаемся по списку приоритетов: 1. Инциденты и алерты (бросаем всё, спасаем прод). 2. Код-ревью (чтобы процессы команды не стопорились). 3. Помощь коллегам по команде и мелкие задачки. 4. Обращения от других отделов (эскалирования от поддержки, вопросы от бизнеса, помощь другим командам). 5. Рутинная чистка техдолга. Но не всё так просто, сам дежурный тоже может столкнуться с трудностями… Ставьте реакции, если хотите почитать про это больше 👀

Разрешите представить наших нейроколлег 🤓 Мы снова про ИИ, но с позиции уже не разработчика, а пользователя. Что видит человек, когда просто учится в Skyeng? Залипательные уроки, крутые учителя, домашка, которую хочется сделать. Вот что под капотом: 1. ChatGPT помогает придумывать задачи и упражнения. 2. NanoBanana Pro рисует к ним иллюстрации: и древних римлян, и Менделеева, и его таблицу. 3. Veo3 «снимает» видео со звуком. Герои двигаются, говорят на английском и других языках, помогают запомнить материал. 4. Suno генерирует песни с новыми словами, чтобы сразу же пропеть их в формате караоке и выучить. Всё это валидируют учителя и методисты, чтобы не было ошибок. Никаких лишних пальцев на фото и «2 + 2 = 5» 👍 Кстати, благодаря ИИ наши ученики по-прежнему могут заказать урок английского на интересную им тему, например про Формулу-1 или BTS. Вы бы какой заказали? 👀

Наш инженер ИИ-автоматизации Артем Азаренков считает, что естественный интеллект сильнее с искусственным. А вот ИИ без вашей экспертизы — просто дорогой калькулятор. Как тестировщики Skyeng используют Cursor, чтобы понять бизнес-логику и фичи на уровне кода? Как сделать так, чтобы n8n сам выгружал баги из тредов в Jira, а Open WebUI объединял их и другие модели в едином интерфейсе? 🔗 Читайте эпопею в трёх частях — от анализа багов до агентов-автоматизаторов: https://habr.com/ru/companies/skyeng/articles/1001488/