Было ли кросс-ревью в команде

Было ли кросс-ревью в команде

Ответ: Да, и это очень важная практика. Расскажу про мой опыт с кросс-ревью и почему это нужно в каждой команде.

Что такое кросс-ревью

Code Review - это проверка кода перед слиянием в main. Обычно код проверяет коллега по проекту.

Кросс-ревью - это проверка кода разработчиком из другой команды или другого проекта. Это более строгая проверка, потому что:

• Человек не знает контекст проекта
• Он видит код "свежим взглядом"
• Он может заметить то, что местные разработчики пропустили

Мой опыт с кросс-ревью

Ситуация: В нашей компании работали два фронтенд-тима:

• Team A - разрабатывала главную страницу
• Team B - разрабатывала админ-панель

Мы внедрили процесс кросс-ревью:

Team A пишет код -> Team B его проверяет
Team B пишет код -> Team A его проверяет

Что мы получили

1. Лучший код качество

// Team A написала:
function formatDate(date) {
  return date.toLocaleDateString(); // работает локально
}

// Team B заметила при ревью:
// "А если date = null? Если это не Date объект?"

// Team A исправила:
function formatDate(date: Date | null): string {
  if (!date) return 'N/A';
  return date.toLocaleDateString('en-US');
}

2. Обмен знаниями

// Team B использовала React Context, который Team A не знала
// Team A: "Классно, мы тоже это применим!"

// Team A использовала Zustand, Team B научилась
// Обе команды стали сильнее

3. Стандарты на весь проект

Без кросс-ревью:
- Team A: используют kebab-case для файлов
- Team B: используют camelCase
- Проект несогласованный

С кросс-ревью:
- Team A: "Может быть одного стиля?"
- Team B: "Согласны! PascalCase для компонентов?"
- Весь проект единообразный

Реальные примеры, что мы ловили

Пример 1: Race condition в API запросе

// Team A написала (неправильно):
const fetchUser = async (id: string) => {
  const data = await api.getUser(id);
  setUser(data); // может перезаписать новый запрос старым
};

// Team B при ревью:
// "Есть race condition! Если кликнуть быстро, старый запрос перезапишет новый"

// Team A исправила:
const controller = useRef<AbortController | null>(null);

const fetchUser = async (id: string) => {
  controller.current?.abort(); // отмени старый запрос
  controller.current = new AbortController();
  
  const data = await api.getUser(id, {
    signal: controller.current.signal,
  });
  setUser(data);
};

Пример 2: Неправильная типизация

// Team A написала:
interface User {
  id: string;
  name: string;
  email: string;
  // но забыли обязательные поля
}

// Team B при ревью:
// "А createdAt? updatedAt? role? Нужны эти поля?"

// Team A обновила:
interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'user';
  createdAt: Date;
  updatedAt: Date;
  isActive: boolean;
}

Пример 3: Performance проблема

// Team B написала:
function UserList({ users }) {
  return (
    <div>
      {users.map(user => (
        <UserCard key={user.id} user={user} />
      ))}
    </div>
  );
}

// Team A при ревью:
// "А что если users 10000? Это замораживает UI!"

// Team B добавила виртуализацию:
import { FixedSizeList } from 'react-window';

function UserList({ users }) {
  return (
    <FixedSizeList height={600} itemCount={users.length}>
      {({ index, style }) => (
        <div style={style}>
          <UserCard user={users[index]} />
        </div>
      )}
    </FixedSizeList>
  );
}

Процесс кросс-ревью в нашей команде

1. Когда PR готов:

git push origin feature/new-feature
git pull-request # создаём PR

2. Запрашиваем ревью от другой команды:

PR description:
"@team-b-reviewer1 @team-b-reviewer2 please review"

3. Ревьювер проверяет:

• Код компилируется
• Нет дублирования
• Типизация правильная
• Есть тесты
• Performance OK
• Accessibility OK

4. Комментарии:

// Team B ревьювер:
"Line 45: используй const вместо let"
"Нужен error handling здесь"
"Test coverage низкий (80%), нужно 90%+"

5. Team A исправляет:

# исправили код
git add .
git commit -m "Address code review comments"
git push origin feature/new-feature

6. Ревьювер одобряет:

"Looks good! Approve"

7. Слияние в main:

git merge feature/new-feature

Лучшие практики кросс-ревью

1. Будьте конструктивны

Плохо: "Это плохой код"
Хорошо: "Можем ли здесь использовать const вместо let для улучшения читаемости?"

2. Объясняйте почему

Плохо: "Удали эту переменную"
Хорошо: "Эта переменная используется только один раз, можно напрямую подставить значение"

3. Предлагайте решение

Плохо: "Здесь проблема с производительностью"
Хорошо: "Здесь может быть bottleneck. Попробуй добавить React.memo() для оптимизации"

4. Не будьте педантичны в мелочах

Важно: bug, security, performance, maintainability
Не важно: 2 пробела vs 4 пробела (это делает prettier)

Отношение к критике

Что я делаю, когда получаю замечания:

1. Спокойно читаю комментарии
2. Согласен или уточняю: "Хм, интересно. А почему ты считаешь это не оптимально?"
3. Если согласен - исправляю
4. Если не согласен - обсуждаю
5. Благодарю за внимание

Reviwer: "Может быть useCallback здесь помочь?"
Я: "Спасибо! Давайте разберёмся. В этом случае useCallback не поможет, потому что зависимость меняется каждый раз. Но я добавлю мемоизацию для дочерних компонентов"
Reviwer: "Хорошо, имеет смысл!"

Проблемы, которые мы решили через кросс-ревью

1. Security issues

// Можно ли доверять данным из URL?
const userId = useParams().id; // это может быть injection

// Ревьювер: "Нужно валидировать UUID перед использованием"
if (!isValidUUID(userId)) return <Error />;

2. Accessibility

// Team A забыла про alt для изображений
Team B: "Нужно добавить alt текст для скрин-ридеров"

3. Browser compatibility

// Team B использовала новый API
Team A: "Это не поддерживается в Safari. Нужен polyfill"

Метрики улучшений

После внедрения кросс-ревью:

• Bugs в production упали на 40%
• Code coverage вырос с 75% до 92%
• Time to fix bugs сократилось в 2 раза
• Team knowledge распределилась равномерно

Итог

Кросс-ревью - это не критика, это помощь.

Оно помогает:

1. Писать лучший код
2. Учиться у других
3. Избегать ошибок
4. Соблюдать стандарты
5. Делиться знаниями
6. Строить доверие в команде

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