В жизни каждого разработчика наступает такой момент, когда нужно отдать свой код коллегам на проверку. Я всегда не любил этот процесс: несколько дней твоей кропотливой работы сталкиваются с критическим взглядом со стороны. И вот теперь ты не просто разработчик, а адвокат своего решения, парирующий пассивно-агрессивные комментарии коллег, которые, уж конечно, всегда знают, как лучше. И это, в принципе, довольно популярное мнение среди сообщества.
Чуть больше года назад наша команда на работе стала расширяться. С двух фронтендеров на проекте мы выросли до четырех (а сейчас вообще до 10, но это уже другая история), и это повлекло за собой предсказуемые сложности:
- Если двум людям довольно легко синхронизироваться под определенный код-стайл, архитектуру приложения, то четырем придется потратить больше усилий и времени.
- Стало сложнее ориентироваться в новых классах, утилитарных функциях - это порождало дублирование логики и увеличение кодовой базы.
- Поддерживать код, написанный другими коллегами, очень тяжело, если видишь его впервые.
- “Откуда здесь это вообще взялось? Зачем это нужно?” - часть коллег перестали понимать бизнес-ценность чужих задач.
- Количество багов в приложении увеличивалось от спринта к спринту, рос техдолг.
“Надо наладить код-ревью” - решили мы после очередного спринта, закрытого с кучей багов. Вы уже знаете, как я люблю этот процесс, поэтому именно мне "повезло" первому обкатать его в команде. Я взял большую задачу, реализовал ее, отполировал до блеска и отправил коллегам код на
В тот раз под своим трудом я собрал больше 100 комментариев за сутки. Это мой абсолютный рекорд хайпожорства, вот бы я когда-нибудь на канале столько собирал.
Шутки шутками, там были как комментарии по делу, так и довольно субъективные решения, с которыми уж очень хотелось поспорить. На обсуждение этой задачи мы потратили несколько напряженных дней (в интернете кто-то не прав!), к консенсусу не пришли и задержали команду тестирования, которая готовилась искать баги. Ну и релиз новой версии тоже задержали, стоит ли упоминать.
В общем, с первого раза сделать все красиво, "как в серьезных компаниях", у нас не получилось. После спринта мы сели за разбор полетов и нашли несколько слабых мест в нашей реализации ревью:
❌ Не все понимают, с какой целью вообще проводится ревью - 100+ комментариев как следствие этого непонимания.
❌ Не всем хорошо даётся коммуникация в рамках ревью (а точнее, всем не даётся) - поэтому многие комментарии коллег читаются токсично. Особенно с точкой на конце, ну, вы знаете.
❌ Не установлены рамки, сроки и критерии завершения ревью - по этой причине мы задержали передачу новой фичи тестировщикам.
В конце концов мы закрыли все перечисленные слабые места и полноценно включили код-ревью в наш процесс разработки. О том, какие решения находили, и как я перестал негативно воспринимать ревью, расскажу в постах дальше.