Хабр, привет! Меня зовут Дмитрий. Я более 17 лет пишу на .NET, а последние 3 года работаю старшим разработчиком серверной логики. В компании более 100 .NET-разработчиков и множество команд.

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

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

Терминология

Полностью термин кросс-ревью звучит как: кросс-тим код-ревью, что обозначает проверка кода между командами (среди команд, перекрёстная проверка).

Личное отношение: как я изменил своё мнение о ревью

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

Эксперимент: как я пошёл ревьюить код в другие команды

Итак, в нашей команде нас было всего двое, и ревьювить почти нечего было. Чтобы не потерять навык и расширить кругозор, я поступил просто: пошёл в соседние отделы.

Познакомился с разработчиками из двух других команд, объяснил, что хочу помочь и заодно поучиться. Нашёл тех, кто был не против такого «внешнего аудита», получил доступы к их репозиториям и начал периодически заходить в их MR-ы.

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

Почему это важно: в чём отличие от простого код-ревью

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

1. Помощь в код-ревью для маленьких команд. Особенно остро эта проблема стоит, где 1-2 разработчика в команде.

2. «Свежий взгляд» — это не просто метафора. Этот пункт имеет особенное место, потому что, когда ты смотришь на свой код своей команды, то «глаз может замылится».
   Человек из другой команды, видит код без контекста и легко замечает логические дыры или странные решения. Да, и у него со временем может "замылится". Но и тут есть выход - предложить ревью ребятам из другой команды.

3. Повышение ответственности. Когда знаешь, что твой код увидят коллеги, а особенно из соседней команды, невольно начинаешь писать аккуратнее. Это работает как психологический якорь: «Стыдно будет, если на мою неряшливость укажут еще и соседи».

4. Живая передача опыта во вне команды. Комментарии к коду в MR-ах — это как передача опыта от одного другому. И чем больший охват людей смотрят твой код, тем больше и шире происходит этот обмен опытом в рамках целого отдела разработки. Больше вероятность подсмотреть новый паттерн или, наоборот, подсказать коллеге более элегантное решение.

5. Фиксация общих подходов становится легче. Чем шире круг людей, проверяющих код, тем больший охват использования общих практик, которые можно согласовать и зафиксировать для всех в уставе.

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

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

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

Но вот, что точно отличает...

Обратная сторона медали

Конечно, не всё так радужно. Кросс-командное код-ревью — это всегда про общение и взаимодействие с коллегами по соседству.

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

• Токсичность. Если ревьювер пишет агрессивно, в стиле «это полный бред», «ты что, не умеешь читать документацию?», — это давит и демотивирует вдвойне. Одно дело, когда ревьювер из твоей команды. А тут - пришёл вообще какой-то левый и начал "качать права".

• Споры из-за разных подходов. Бесконечные споры о том, ставить фигурную скобку на новой строке или нет, использовать LINQ или цикл. Такие дискуссии могут длиться часами и убивать рабочее настроение. Особенно, если в другой команде совсем другой стиль и привычки как писать код.

• Работа вне команды. Обычно ты должен работать в рамках своей команды. А любой тим-лид не очень хочет, чтобы его подчиненные "отвлекались по сторонам". Это создает дискомфорт и желание вообще ничего не делать для других.

Обратная связь от «заказчика»

Через несколько месяцев я решил подвести промежуточный итог и попросил обратную связь у тим лида команды, в которую я «внедрился». Мне было критически важно понять: полезен ли мой волонтёрский опыт или я просто отвлекаю людей?

Вот, что мне ответили:

«В целом думаю нормально. Плюсы — взгляд со стороны: что-то могут подсветить, о чём сам не задумывался. Минусы — без погружения в проект в основном можно увидеть только недостатки, связанные со стилем кода, опечатки или криво написанную функцию».

Так же я спросил ещё и самих разработчиков других команд: каждый отмечал что-то своё. Но не было какого-то большого негатива.

И я был рад! Да, это не глубокий рефакторинг архитектуры (для этого нужно знать контекст), но даже «чистка опечаток» и унификация стиля — это уже полезно. Значит, эксперимент и подход вцелом удался, и я планировал масштабировать его на другие проекты.

Резюме и планы на будущее

Для себя я сделал простые выводы:

1. Кросс-тим ревью работает. Оно приносит пользу, даже если внешний ревьювер не знает всех нюансов бизнеса.

2. Код-ревью — это про уважение и передачу опыта не только внутри команды.

3. Ошибки делают все. Мы люди. У кого-то сильная архитектура, кто-то лучше знает конкретную библиотеку. Командная работа сглаживает эти индивидуальные недостатки. А кросс-командная ещё больше.

В ближайших планах: провести ревью еще в нескольких командах. Амбициозная цель — дойти до всех команд в компании. Шаг за шагом.

Вводите практику кросс-тим код-ревью, если у вас её нет, и не бойтесь выходить за рамки своей команды. Делитесь опытом в комментариях!

P.S. Это первая часть статьи моего эксперимента. Если вам интересно узнать больше о конкретных кейсах, багах, которые я замечал, или холиварах, в которые мы вступали, — пишите в комментариях, расскажу во второй части. Но тут больше не про процесс, а про идею и подход.

Всем большое спасибо за внимание!