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

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

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

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

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

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

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

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

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

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

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

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

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

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