На что обращаешь внимание при код ревью?

Системный подход к код ревью

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

Архитектура и дизайн

Сначала я смотрю на общую структуру решения:

• Соответствует ли код архитектурным принципам проекта (Clean Architecture, DDD, SOLID)?
• Не нарушены ли слои зависимостей?
• Есть ли очевидное дублирование, которое можно вынести в общую функцию или класс?

Пример проблемы:

# ❌ Плохо: логика бизнеса смешана с HTTP слоем
@router.post('/users')
def create_user(data: dict):
    if len(data['password']) < 8:
        raise Exception('Пароль слишком короткий')
    db.save(data)
    return data

# ✅ Хорошо: разделение ответственности
class UserService:
    def create_user(self, user_data: UserData) -> User:
        if not self._is_valid_password(user_data.password):
            raise InvalidPasswordError('Пароль слишком короткий')
        return self._user_repo.save(user_data)

@router.post('/users')
def create_user(data: UserCreateRequest):
    user = user_service.create_user(data)
    return UserResponse.from_domain(user)

Логика и корректность

Я проверяю правильность алгоритма:

• Обрабатываются ли граничные случаи (пустые массивы, None, отрицательные числа)?
• Нет ли логических ошибок, особенно в условных выражениях и циклах?
• Правильно ли используются асинхронные операции (await, создание задач)?

Производительность

• Есть ли очевидные N+1 запросы к БД?
• Не создаются ли ненужные объекты в цикле?
• Не используется ли блокирующий код в асинхронных функциях?

Пример:

# ❌ N+1 запрос
for user_id in user_ids:
    user = db.session.query(User).filter(User.id == user_id).first()
    print(user.name)

# ✅ Правильно: один запрос
users = db.session.query(User).filter(User.id.in_(user_ids)).all()
for user in users:
    print(user.name)

Тестируемость

• Код легко тестировать или его нужно рефакторить?
• Есть ли зависимости, которые должны быть injected вместо hardcoded?
• Покрыто ли критически важное логикой тестами?

Читаемость и стиль

• Понятные ли имена переменных, функций, классов?
• Не слишком ли длинные функции (ideally < 20 строк)?
• Соответствует ли код стайл-гайду проекта (PEP 8, форматирование)?
• Есть ли комментарии там, где логика неочевидна?

# ❌ Плохие имена
def f(x, y):
    return [z for z in x if z > y]

# ✅ Хорошие имена
def filter_values_above_threshold(values: list[int], threshold: int) -> list[int]:
    return [val for val in values if val > threshold]

Обработка ошибок

• Обрабатываются ли исключения или они просто проходят мимо?
• Используются ли правильные типы исключений?
• Есть ли логирование ошибок?

Безопасность

• Проверяется ли пользовательский ввод?
• Используются ли параметризованные запросы к БД (защита от SQL injection)?
• Нет ли утечек конфиденциальных данных в логах?

Типизация (для Python с type hints)

• Все ли функции имеют type hints?
• Можно ли усилить типизацию (избежать Any)?

# ❌ Слабая типизация
def process(data):
    return [x * 2 for x in data]

# ✅ Хорошая типизация
def process(data: list[int]) -> list[int]:
    return [x * 2 for x in data]

Мой подход к диалогу

Я не говорю "это плохо", я говорю "давайте обсудим это решение: что ты имел в виду?" Сначала слушаю, потом предлагаю альтернативы. Код ревью — это возможность обмена знаний, а не критика. Это гарантирует, что команда растёт вместе и код становится лучше.