Код-ревью: что смотреть и как говорить

На собесе код-ревью встречается в двух формах: вопросы «как ты ревьюишь» и практическая задача «вот компонент, найди проблемы». Во второй оценивают, что ты находишь, в каком порядке и как формулируешь.

Порядок просмотра

Иди от важного к мелкому, иначе утонешь в отступах и пропустишь баг.

1. Задача. Решает ли PR то, что заявлено? Нет ли лишнего?
2. Корректность. Баги, краевые случаи (пустой массив, null, ошибка сети, двойной клик), гонки.
3. Безопасность. XSS (dangerouslySetInnerHTML без санитизации), секреты в коде, доверие данным с клиента.
4. Архитектура. Границы модулей, правильное место кода, связность.
5. Производительность. Лишние ререндеры, запросы в цикле, утечки (не снятые подписки и таймеры).
6. Читаемость. Имена, размер функций, комментарии «почему», а не «что».
7. Тесты. Есть ли, проверяют ли поведение, а не реализацию.
8. Стиль. Это должен ловить линтер и форматтер, а не человек.

Типичные находки в React-коде

function UserList({ query }) {
  const [users, setUsers] = useState([]);
  useEffect(() => {
    fetch('/api/users?q=' + query)           // 1. нет encodeURIComponent
      .then(r => r.json())                   // 2. не проверен r.ok
      .then(setUsers);                       // 3. гонка: старый ответ перетрёт новый
  }, []);                                    // 4. query не в зависимостях
  return users.map((u, i) =>
    <div key={i} onClick={() => select(u)}>{u.name}</div>  // 5. key=index, 6. div вместо button
  );
}

Что сказать: добавить query в зависимости, отменять прошлый запрос через AbortController или флаг в cleanup, проверять r.ok, кодировать параметр, использовать стабильный key={u.id} и интерактивный элемент button для доступности. Ещё лучше вынести загрузку в TanStack Query.

Другие частые находки: мутация состояния (state.push), копирование пропсов в state, useEffect для вычисления производного значения, неснятый addEventListener или setInterval, any в TypeScript, магические числа, проглоченные ошибки в catch {}.

Как писать комментарии

• Обсуждай код, а не человека: «здесь возможна гонка», а не «ты не подумал».
• Объясняй почему и предлагай вариант.
• Помечай важность: blocker, nit (мелочь, не блокирует), question. Многие команды используют соглашение Conventional Comments.
• Хвали удачные решения, это тоже часть ревью.
• Если обсуждение больше трёх реплик, созвонись.

Как сделать ревью быстрым

• Маленькие PR (условно до 400 строк диффа) ревьюят внимательнее и быстрее.
• Автоматизируй рутину: линтер, форматтер, типы, тесты в CI до человека.
• Описание PR: что, зачем, как проверить, скриншоты для UI.
• Договорись о сроке ответа на ревью в команде.

Что спросят на собесе

• На что смотришь в первую очередь при ревью?
• Найди проблемы в этом компоненте (практика).
• Как пишешь комментарии, чтобы не было конфликтов?
• Что делать с огромным PR?
• Как поступишь, если автор не согласен с твоим замечанием?