Код-ревью и Рингельман
Код-ревью в команде — это как смотрины при рождении ребенка — большой семейный праздник. Разработчик вытаскивает своё творение на всеобщее обозрение и ждёт приговора, похвалы, замечаний и комментариев. Главная цель — показать изменения, которые вносятся в кодовую базу, а в ходе рецензирования повысить экспертизу как минимум одного участника дискуссии и не допустить плохой код до прода.
В небольших командах этот праздник жизни обычно проходит довольно спокойно. В командах до 4-х, 5-ти человек организовать код-ревью довольно легко. Там работают несколько парадигм:
Код-ревью — на первом месте: каждый должен просмотреть MR и выразить своё мнение. Люди останавливают свою работу и первым делом смотрят задачу коллеги.
Альфач-схема — техлид, тимлид, синьор-помидор проводят в одиночку ревью, и одного их мнения хватает.
Интеллектуальная анархия — команда очень крутая, и ревью там опционально, всё построено на доверии друг к другу. Вещь редка как единорог, но так же прекрасна.
Проблемы начинаются с ростом команды.
Больше тиммейтов, больше задач, больше кодовая база. Состав команды также становится разнородным, есть новенькие или джуны, есть те, кто больше знает про продукт, есть те, кто меньше. Знания начинают хуже передаваться между сотрудниками. Каждый вовлечён в свою задачу или область, и охватить все остальные ему сложно. Продолжая аналогию с семейным праздником, дядя сцепился с бабушкой в разговоре за политику, внуки на кухне делают огуречно-кефирный коктейль с селёдкой, деверь вернулся после отсидки на корпоративном предприятии и теперь рассказывает про то, что ваш код-стайл говно. А писать надо «по понятиям», а дед уже давно выгорел возле батареи и молчит.
Частая проблема — это то, что при рецензировании кода люди начинают токсично кидаться друг в друга неэстетичными предметами и вспоминать чьих-то матушек и их публичные и приватные эндпоинты. Чем больше людей и личностей, тем больше конфликтов. Беседа не идёт в конструктивном ключе. Хорошая практика при переходе в новую команду или компанию вне зависимости от её размера — попросить показать последние 20–30 дискурсов из обсуждений, возможно, вы передумаете туда переходить и выучите новые слова и выражения (цитата месяца: «Ты так БД сложишь своими мелкими тентакль-пенетрациями»). Редактор нашего блога попросил вставить в текст упоминание нашей компании, так что могу сказать, что эту фразу я точно видел не в Каруне и не в своей команде.
Другая проблема: команда начинает обсуждать имена переменных, куда положить бизнес логику, или то, что можно написать? Это всё в другой парадигме. В лучшем случае это будет долгая аргументированная беседа, где каждый будет трясти своими доводами, или всё скатится в предыдущий пункт. Худший вариант — «Сюрприз». Это когда после реализации, на ревью, после битвы в комментах, вы решаете делать по-другому. В итоге у вас не одна задача, а две. А если это фуллстек задача — то четыре. За себя и за Сашку.
Чем больше команда, тем менее продуктивен и вовлечён каждый её член.
Чем больше команда, тем менее продуктивен и вовлечён каждый её член. Это третья проблема. Она же — эффект социальной лени или эффект Рингельмана. Большинство задач просматривают техлид и ещё пара людей, у которых «болит душа» за кодовую базу — и им, если что, чинить прод. Из-за такого перекоса и задачи дольше проходят ревью, и люди начинают относиться к ревью как к линтеру — можно написать странное, потом напишут, что поправить.
Почему так происходит? Разные часовые пояса, периоды активности, разная степень вовлечённости. Кто-то боится высказываться, потому что думает, что его мнение не важно, или не считает себя экспертом. Кому-то искренне лень. Кто-то наоборот идёт в каждую задачу и начинает забирать на себя больше ответственности. В итоге — увеличение лид-тайма, выгорание ответственных, понижение экспертизы исполнителей, торжество проклятого старика Рингельмана!
Давайте попробуем найти ответы на два вечных вопроса: кто виноват, и что делать?
Токсичность на код-ревью — это самый простой и самый сложный пункт. Если это не слишком запущенный процесс, то обычный разговор, договорённости о том, что не надо начинать дискуссии со слова «бл*» решают проблему. Сложнее, если у вас уже есть конфликты между отдельными членами команды: тут их придётся решать лично, в худшем случае — с изгнанием токсиков из храма науки и технологий.
Споры о стилистике, техническом решении и парадигмах — это показатель того, что вам нужно улучшать процессы, регламенты, проработку и максимально автоматизировать проверку тех или иных кейсов, или договориться о правилах в команде. Тут на самом деле широкий набор инструментов: дополнения линтера своими внутрикомандными правилами, подключение анализаторов кода типа SonarQube, специальных библиотек, которые дополнительно проверят код на уязвимости или на проверку типичных проблем для работы с хайлоадом. Составляйте и заставляйте людей пользоваться чек-листами перед ревью кода. Фиксируйте договоренности кровью в конфлюэенсе. Явное — лучше, чем неявное. И это правило работает не только при реализации в кодовой базе, но и в разработке вообще.
Вот примеры хороших стайлгайдов (которые вы наверняка тоже видели):
С Рингельманом тоже можно и нужно бороться. Самый первый вариант — это, конечно, микромеджмент и тоталитаризм. Тимлид назначает каждому разработчику задачу для ревью, его зону ответственности, вьётся над ним, словно черный ворон. Это быстрый, но очень пагубный и неверный путь. Как любой тоталитарный режим, ваш падёт моментально, с первым отпуском, випассаной или запоем тимлида.
Создавайте рабочие группы, пробуйте парное программирование, делегируйте ответственность, главное — вовлечь каждого. У нас есть отдел автоматизации (храни их Господь!). Поэтому тоталитарный микроменджемент мы заменили на святой рандом и бота, который выдаёт нотификацию с мемасиком, как только задача переходит в ревью. Реализовать такого бота — довольно просто самостоятельно, всё зависит от вашей инфраструктуры и инструментария. Мы в Каруне использовали N8N+Jira+Slack, можно самому написать небольшой сервис, который будет подходить вам, или попробовать посмотреть варианты соорудить что-нибудь на github actions, баш скриптах, или ещё чем-либо. Тут серебрянной пули нет — нужно искать (и, вероятно, костылить) что-то своё.
В очень недалёком будущем, а для кого-то — уже в настоящем — нас ждёт торжество AI-ревьюеров, систем, которые будут в контексте всего вашего проекта, которые не будут оставлять токсичные комментарии, сами править явные ошибки. Но пока сингулярность не наступила, командное рецензирование написанного кода — один из ваших главных quality gates. И главное, чтобы стража честно их охраняла, а не играла в нарды или предавалась мордобою.
