Код-ревью: как не тормозить, а ускорять поставку продукта. Часть - 1. Код-ревью – процесс, с которым вы сталкиваетесь практически ежедневно, особенно когда команда по одному стеку переваливает за 5 человек. В такой конфигурации с высокой долей вероятности у вас будет 2–3 (а то и больше) Pull Request'а в день, которые нужно отревьюить, апрувнуть, отдать в тестирование/довести до прода. Этот этап критически влияет на T2M (time-to-market) любой задачи. Почему? Потому что в него вовлекается сразу несколько этапов. Стандартный PR требует времени и внимания: - от автора, который этот код писал; - от ревьюеров, которые его читали, обсуждали, вносили замечания и ожидали исправлений; - от тестировщиков, которые получили инкремент (и не факт, что рабочий) после ревью. И если процесс устроен неэффективно, ревью превращается из полезного инструмента в узкое горлышко, которое стопорит всю цепочку поставки. В этом посте я не буду рассказывать, как ревьюить код (об этом отдельно). Сейчас я сосредоточу внимание на принципах и практиках, которые помогают мне лично быстро и качественно деливерить продукт, не теряя при этом качество и не сжигая время команды. 1. Убираем единственного ревьюера Первое, на чём часто ломается скорость – это модель, где есть один главный ревьюер (обычно самый сеньористый человек в команде), который должен видеть всё. Это работает только на бумаге. На практике: - ревью ждут, пока он освободится; - обсуждения затягиваются; - люди реже вникают в чужие задачи – “всё равно Вася посмотрит”. Вместо этого я сторонник подхода, когда любая задача может быть отревьюена любым участником команды, независимо от грейда и должности. Что это даёт: - повышается насмотренность всей команды, а не только у одного человека; - быстрее приходит фидбэк и вам не нужно ждать, когда у главного ревьюера будет время; - возникает больше обсуждений, а значит, коллективный уровень растёт; - исчезает бутылочное горлышко, тормозящее T2M. Если вы всё равно хотите финальный взгляд от того самого эксперта – не проблема, попросите. Но не делайте его единственным звеном, от которого зависит качество кода. 2. Внутренние гайдлайны: договариваемся, фиксируем, используем Да, есть PEP'ы, есть best practices, описанные умными дядьками. Это хорошо. Но в реальной команде всегда есть внутренние соглашения, которые не менее важны: - как мы называем сущности; - какую структуру мы используем в проектах; - как оформляем логику бизнес-слоёв; - что выносим в утилиты; - как форматируем, пишем docstring'и и т.д; Вот это всё – критично. И если оно не зафиксировано, то каждая ревью-сессия превращается в “мне кажется, что тут лучше вот так”. Поэтому я настоятельно рекомендую: - заведите страницу в Confluence или хотя бы Readme в репозитории; - опишите в ней основные правила по архитектуре, кодстайлу, неймингу, форматированию (+ линтеры с анализаторами в помощь); - договаривайтесь на лету, по ходу обсуждений, и фиксируйте эти договоренности в гайдлайне. Это сэкономит кучу времени, снизит порог входа для новичков, и даст ревьюерам конкретную опору, а не “чисто субъективное мнение”. 3. Если обсуждение в PR превратилось в чат – зовите третьего Бывает так, что в треде кода начинается затяжной спор. 5–6 сообщений туда-сюда, и ни одна сторона не хочет уступать. Это нормально, ведь у каждого может быть своя точка зрения. Но здесь есть важное правило: Если обсуждение превысило 3–4 реплики, то зовите третьего человека. Он поможет: - разрулить спор со свежим взглядом; - подсветить альтернативу, на которую вы оба не смотрели; - принять финальное решение и зафиксировать его в гайдлайне (если кейс повторяется). Так вы не тратите время на бесконечные переписки и двигаетесь дальше по задаче. Наша цель – поставить продукт, а не выяснять, чья архитектура "чище".