Что не пропустишь на Merge Request?

Моя стратегия проверки Merge Request: качество, безопасность и долгосрочная поддержка

При проверке Merge Request (MR) я сосредотачиваюсь не только на функциональности, но и на архитектурной целостности, читаемости кода и минимизации будущих рисков. Вот ключевые пункты, которые я никогда пропускаю.

1. Согласованность с архитектурой и соглашениями проекта

Первое, что я проверяю — соответствует код принятым в проекте архитектурным паттернам и конвенциям именования.

// Плохой пример: нарушение соглашений (смесь camelCase и snake_case)
function get_user_data(userId) {
    // ...
}

// Хороший пример: соблюдение camelCase для функций и переменных
function getUserData(userId) {
    // ...
}

Я всегда сверяюсь с существующим кодом и документацией проекта. Если в проекте используется Feature-Sliced Design (FSD), Atomic Design или другой подход, новый код должен его соблюдать. Создание новой папки components рядом с уже существующим слоем features — это красный флаг.

2. Качество и читаемость кода

Я категорически не пропускаю "магические числа", жестко закодированные строки и неочевидные логические условия.

// Плохой пример: "магическое число", сложная логика
if (status === 3 && userType === 'A') {
    // Что такое статус 3? Что такое тип 'A'?
}

// Хороший пример: использование констант и ясных условий
const STATUS_ACTIVE = 3;
const USER_TYPE_ADMIN = 'ADMIN';

if (status === STATUS_ACTIVE && userType === USER_TYPE_ADMIN) {
    // Логика ясна
}

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

3. Обработка ошибок и граничные случаи

Любой код, особенно связанный с API-вызовами, формами или обработкой данных, должен учитывать сценарии ошибок и граничные условия.

// Плохой пример: отсутствие обработки ошибок и граничных случаев
async function fetchData(url) {
    const response = await fetch(url);
    const data = await response.json();
    return data;
}

// Хороший пример: обработка ошибок сети, статусов ответа, пустых данных
async function fetchData(url) {
    try {
        const response = await fetch(url);
        if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        }
        const data = await response.json();
        // Проверка на наличие данных
        if (!data || Array.isArray(data) && data.length === 0) {
            throw new Error('Received empty data set');
        }
        return data;
    } catch (error) {
        // Логирование ошибки для дебаггинга
        console.error('Fetch failed:', error);
        // Возврат безопасного fallback состояния для UI
        return { items: [] };
    }
}

Я проверяю: обрабатываются ли ошибки сети? Что происходит при null или пустом массиве? Как форма реагирует на невалидный ввод?

4. Влияние на производительность и оптимизации

В фронтенде производительность напрямую влияет на пользовательский опыт. Я всегда проверяю:

• Неоптимальные рендеры в React: отсутствие мемоизации (useMemo, useCallback) для тяжелых вычислений или функций, передаваемых в child-компоненты, что приводит к ненужным ререндерам.
• "Утечки" памяти: например, неочищаемые EventListener или Interval в хуках.
• Критические рендер-блокирующие ресурсы: добавление больших библиотек без анализа или импорт всего модуля вместо selective import.

// Плохой пример: функция создается при каждом рендере, вызывая ререндеры детей
function ParentComponent() {
    const handleClick = () => { /* ... */ };
    return <ChildComponent onClick={handleClick} />;
}

// Хороший пример: мемоизация функции с useCallback
function ParentComponent() {
    const handleClick = useCallback(() => { /* ... */ }, []);
    return <ChildComponent onClick={handleClick} />;
}

5. Тестирование и сопровождаемость

MR без тестов или с неполным покрытием тестов я отправляю на доработку. Тесты — это не просто формальность, это документация ожидаемого поведения и гарантия против регрессий.

// Пример хорошего теста: проверяет основную логику и граничный случай
describe('calculateDiscount', () => {
    it('should apply 10% discount for premium users', () => {
        expect(calculateDiscount(100, 'PREMIUM')).toBe(90);
    });
    it('should return original price for invalid user type', () => {
        expect(calculateDiscount(100, 'INVALID')).toBe(100);
    });
});

Я проверяю наличие юнит-тестов для сложной бизнес-логики, интеграционных тестов для компонентов и, если возможно, скриншотных тестов для UI.

6. Безопасность и санитизация данных

На фронтенде тоже есть угрозы безопасности. Я обращаю внимание на:

• Инъекции через innerHTML или динамическое создание скриптов.
• Отсутствие санитизации пользовательского ввода перед отправкой на бэкенд или отображением.
• Уязвимости в зависимостях (проверяю, не добавляются ли библиотеки с известными security issues).

7. Соответствие задаче и отсутствие "скрытых" изменений

Я сравниваю код MR с описанием задачи в тикете. Добавление "дополнительного функционала", который не был согласован, — частый источник будущих багов и конфликтов. Если MR решает проблему X, но также "небольшими изменениями" меняет логику в соседнем модуле Y, я задаю вопрос: почему это было необходимо и было ли это обсуждено?

Итог

Мой подход к MR — это взгляд инженера, который будет поддерживать этот код через год. Я стремлюсь к тому, чтобы каждый коммит не просто "работал", но и соответствовал стандартам проекта, был понятен коллегам, готов к изменениям и минимально рискован. Это требует времени на ревью, но экономит огромные ресурсы на исправление ошибок и рефакторинг в будущем.