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

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

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

А, может, у вас тоже есть истории про необычный или креативный мерч, который вы получали от компаний?)

Терпеть не могу код ревью (1/4)

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

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

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

“Надо наладить код-ревью” - решили мы после очередного спринта, закрытого с кучей багов. Вы уже знаете, как я люблю этот процесс, поэтому именно мне "повезло" первому обкатать его в команде. Я взял большую задачу, реализовал ее, отполировал до блеска и отправил коллегам код на растерзание оценку.

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

Шутки шутками, там были как комментарии по делу, так и довольно субъективные решения, с которыми уж очень хотелось поспорить. На обсуждение этой задачи мы потратили несколько напряженных дней (в интернете кто-то не прав!), к консенсусу не пришли и задержали команду тестирования, которая готовилась искать баги. Ну и релиз новой версии тоже задержали, стоит ли упоминать.

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

❌ Не все понимают, с какой целью вообще проводится ревью - 100+ комментариев как следствие этого непонимания.
❌ Не всем хорошо даётся коммуникация в рамках ревью (а точнее, всем не даётся) - поэтому многие комментарии коллег читаются токсично. Особенно с точкой на конце, ну, вы знаете.
❌ Не установлены рамки, сроки и критерии завершения ревью - по этой причине мы задержали передачу новой фичи тестировщикам.

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

Да да, телега выкатила бусты для каналов.

1 буст и я начну постить истории.
https://t.me/alek_dev?boost

Ок.

Терпеть не могу код ревью (2/4) - Цели

Итак, первая попытка в код-ревью прошла ужасно: мы сорвали сроки, много времени решали, как правильно писать код, а как - нет, и настроение в команде было напряженное.

Мы собрались на разбор полетов, и каждый высказал свое видение, почему наш опыт был неудачным. Вдруг кто-то спросил: “Мы столько времени потратили, сорвали сроки, перессорились, может, нам вообще не проводить ревью?”. Вопрос встретила тишина, потому что за всеми спорами мы забыли про цели, которые мы преследуем, внедряя код-ревью.

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

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

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

Если разработчик отдал код на ревью, который по своей архитектуре отличается от того, к чему привыкли остальные - такая штука не пройдет проверку. Да, если мы сейчас вольем эту фичу, то уменьшим Lead Time в моменте (и порадуем заказчика), но значительно проиграем в этой же метрике позже, когда начнем дорабатывать этот грязный код.

Чтобы писать код так, как принято в команде, мы завели отдельную страничку в confluence (вики) и верхнеуровнево описали наш подход и ключевые моменты, на которые стоит обратить внимание + расшарили на всех настройки IDE и почти выровняли правила для линтеров между проектам.

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

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

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

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

✅ Находить лучшее решение совместно
Зачем нужна эта цель: уменьшение багов, снижение техдолга, обучение сотрудников.

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

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

Это позволяет как совместно обучаться (причем не только ревьюверу и разработчику, но и наблюдателям), так и исправлять баги до того, как QA начнет искать их.

———————————————————————

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

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

Терпеть не могу код ревью (3/4) - Регламент

Мой первый PR (pull/merge request - запрос на внесение изменения в код проекта) в рамках нашего нового процесса провисел несколько суток и задержал релиз. Дискуссия под моим кодом с каждым днем только увеличивалась: коллеги продолжали спорить над тем, что уже было исправлено, и начинали новые ветки комментариев под теми частями, за которые не успели зацепиться ранее.

Чтобы не повторять такой опыт, мы договорились о регламенте ревью, который установил рамки в этом процессе:
- Все, что не относится к целям ревью (из предыдущего поста) - не является предметом ревью.
- Ответственный за PR - его автор. Он следит за тем, чтобы ревьюверы не забыли прожать галочку, когда код можно вливать в основную ветку.
- Разработчик вправе не исправлять каждое замечание.
- Однако, есть критичные замечания, которые обязательны к исправлению. Такие ревьювер должен выделять, чтобы они не затерялись среди других комментариев.
- Концептуальные вопросы выносятся на обсуждение в общий чат и позднее закрепляются в стайл гайде (та самая страничка в нашем confluence/wiki), куда можно ссылаться в следующий раз.
- Ревью подлежит только новая функциональность, но не исправления багов.
- Критикуя, оставляй предложения.
- Ревью не только для замечаний: узнали что-то новое из PR своего коллеги, или увидели, что качество кода возросло - отметьте это и похвалите.

После этого мы договорились об ограничениях в сроках проверки PR. Это было нужно, чтобы не затягивать ревью на несколько дней. Помимо этого, определили минимальное условие, необходимое для вливания кода в основную ветку:
- PR “живет” всего 24 часа. Это означает, что у ревьюверов есть только сутки на то, чтобы дать комментарии, а у разработчика - исправить замечания.
- Если за первые 4 часа никто не прокомментировал PR, то разработчик должен попросить об этом в общем чате. Это нужно, чтобы не надоедать каждые полчаса напоминаниями о проверке.
- PR может быть влит в основную ветку только после подтверждения хотя бы одного из ревьюверов.

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

Ну а чтобы все было совсем хорошо, мы договорились избегать коротких неконструктивных комментариев по типу “Мы так не пишем, переделай”. По двум причинам:
- Само по себе такое сообщение хоть и экономит секунды жизни ревьювера, но никак не ведет к конструктивному диалогу.
- Разбор того, а как в итоге правильно писать, затягивается надолго, поэтому и есть правило “критикуя, предлагай”. Тем самым, автор PR не дожидается следующих комментариев коллеги.

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

Спойлер к следующей серии

Собеседования дизайнеров

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

Собес у дизайнеров - это, оказывается, отдельный удивительный мир. Чтобы вы понимали, из чего состоит типичное собеседование для разработчика:
1. Прескрининг с HR: могут задать вопросы по теории, в которых сам HR ничего не понимает, но за ошибки отсекут уже здесь
2. Технический собес:
- Рассказ о своем опыте + к рассказу могут последовать более глубокие технические вопросы
- Устная секция “вопрос-ответ” по основам языка программирования и необходимой базе, без которой ты не сможешь работать
- Лайв-кодинг с углубленными вопросами, с озвучиванием размышлений, с объяснениями решений, со спорами, дискуссиями и т.д.
3. Собес на софт-скиллы или, как мы его называем, на адекватность
По желанию еще +2 собеседования по алгоритмам и углубленной теории (Яндекс, привет)

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

Тем временем собес на дизайнера:
1. Прескрининг на софт-скиллы
2. Еще один собес на софт-скиллы + "а фигму можете показать? А компоненты умеете? А автолейауты могёте? Нет, прямо сейчас не нужно делать, мы видим, спасибо"
3. Последний собес на софт-скиллы

Если это не идеальная IT-профессия, то что тогда?