Расскажи, как организован процесс исправления бага

Процесс исправления бага: от обнаружения к деплою

Этап 1: Обнаружение и документирование

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

Что нужно сделать:

• Создать issue в issue tracker (Jira, GitHub Issues, YouTrack)
• Описать симптомы: когда происходит, какой результат, какой ожидался
• Добавить шаги воспроизведения (Steps to Reproduce)
• Прилогать логи, скриншоты, видео если есть
• Выставить приоритет (Critical, High, Medium, Low)
• Выставить severity (блокирует функцию, косметический дефект)

Пример issue:

Title: NullPointerException при загрузке профиля пользователя
Description:
Когда заходу на страницу профиля незарегистрированного пользователя, 
приложение крашится.

Steps to Reproduce:
1. Открыть приложение
2. Перейти по прямой ссылке /profile/non-existent-user
3. Получаю NullPointerException

Expected: показать "User not found" или 404
Actual: Internal Server Error 500

Logs: [stack trace]
Priority: High
Severity: Blocker

Этап 2: Анализ и расследование

Разработчик берёт issue в work:

1. Прочитать полное описание
2. Попытаться воспроизвести баг локально
3. Включить дебаг логирование
4. Проанализировать stack trace
5. Найти root cause

Типичный анализ:

// Баг: NullPointerException в getUserProfile()
public UserProfile getUserProfile(String userId) {
    User user = userRepository.findById(userId);  // может быть null
    return new UserProfile(user.getName(), user.getEmail());  // NPE если user null
}

// Root cause: не проверяем null перед использованием

Если баг не воспроизводится:

• Попросить больше информации у репортёра
• Проверить логи production
• Посмотреть монитор (DataDog, New Relic, CloudWatch)
• Проверить версию приложения

Этап 3: Планирование исправления

Определить:

• Какой компонент затронут (backend, frontend, database)
• Какой слой архитектуры (domain, application, infrastructure)
• Нужна ли миграция БД
• Нужна ли поддержка старых версий
• Есть ли связанные баги

Оценить усилия:

• Простой fix: 15 минут - 1 час
• Средний: 1-4 часа
• Сложный: 4+ часов, может требовать рефактора

Этап 4: Написание теста (TDD подход)

Всегда пиши тест ДО исправления:

public class UserProfileServiceTest {
    @Test
    public void testGetUserProfile_UserNotFound_ReturnNull() {
        // Given
        String userId = "non-existent-user";
        when(userRepository.findById(userId)).thenReturn(null);
        
        // When
        UserProfile profile = userProfileService.getUserProfile(userId);
        
        // Then
        assertNull(profile);
    }
    
    @Test
    public void testGetUserProfile_UserFound_ReturnProfile() {
        // Given
        User user = new User("1", "John", "john@example.com");
        when(userRepository.findById("1")).thenReturn(user);
        
        // When
        UserProfile profile = userProfileService.getUserProfile("1");
        
        // Then
        assertNotNull(profile);
        assertEquals("John", profile.getName());
        assertEquals("john@example.com", profile.getEmail());
    }
}

Запускаем тест - он должен УПАСТЬ (RED).

Этап 5: Исправление кода (GREEN)

Минимальное исправление:

public UserProfile getUserProfile(String userId) {
    User user = userRepository.findById(userId);
    
    // Проверяем null
    if (user == null) {
        return null;  // или выбросить исключение
    }
    
    return new UserProfile(user.getName(), user.getEmail());
}

Лучший подход - использовать Optional:

public Optional<UserProfile> getUserProfile(String userId) {
    return userRepository.findById(userId)
        .map(user -> new UserProfile(user.getName(), user.getEmail()));
}

Контроллер:

@GetMapping("/profile/{userId}")
public ResponseEntity<?> getProfile(@PathVariable String userId) {
    return userProfileService.getUserProfile(userId)
        .map(ResponseEntity::ok)
        .orElseGet(() -> ResponseEntity.notFound().build());
}

Запускаем тест - теперь должен ПРОЙТИ (GREEN).

Этап 6: Рефакторинг (REFACTOR)

Улучшаем код при необходимости:

// До: много кода в сервисе
public class UserProfileService {
    public Optional<UserProfile> getUserProfile(String userId) {
        return userRepository.findById(userId)
            .map(user -> createProfile(user));
    }
    
    private UserProfile createProfile(User user) {
        return new UserProfile(user.getName(), user.getEmail());
    }
}

// После: разделили ответственность
// Service использует Mapper
public class UserProfileService {
    private final UserProfileMapper mapper;
    
    public Optional<UserProfile> getUserProfile(String userId) {
        return userRepository.findById(userId)
            .map(mapper::toProfile);
    }
}

Запускаем все тесты - они должны проходить:

make lint   # проверка кода
make test   # unit тесты
make test:e2e  # e2e тесты

Этап 7: Code Review

Создаём Pull Request:

Title: Fix NullPointerException when loading non-existent user profile

Description:
- Issue: #123 NullPointerException при загрузке профиля
- Root Cause: не проверяли null перед использованием user
- Solution: используем Optional<User> в repository
- Tests: добавили 2 unit теста для граничных случаев

Changes:
- Modified UserProfileService.getUserProfile() to handle null
- Added UserProfileServiceTest with edge case tests
- Changed return type to Optional<UserProfile>

Testing:
- Unit tests: PASS
- Integration tests: PASS
- Coverage: 92% -> 95%

Что проверяет reviewer:

• Правильное ли исправление
• Есть ли регрессионные риски
• Достаточно ли тестов
• Соблюдены ли code style и best practices
• Нужны ли документирование/миграция БД

Этап 8: Merge и Deploy

После одобрения reviewer:

# 1. Убедиться что tests passing
git pull origin main
make test

# 2. Merge в main
git merge feature/fix-npe-user-profile

# 3. Push в main
git push origin main

# 4. Автоматический deploy (CI/CD)
# GitHub Actions / Jenkins / GitLab CI запускает:
#   - Lint
#   - Tests
#   - Build
#   - Deploy to staging
#   - Smoke tests
#   - Deploy to production

Этап 9: Мониторинг

После deploy:

1. Проверить логи production
2. Мониторить метрики (errors, latency, traffic)
3. Проверить, что баг репортер подтверждает исправление
4. Если проблема - rollback
5. Закрыть issue

Мониторинг инструменты:

• DataDog / New Relic - APM метрики
• Sentry - ошибки и исключения
• CloudWatch - логи и алерты
• PagerDuty - oncall уведомления

Этап 10: Post-Mortem

Если был critical баг:

1. Провести встречу команды
2. Выяснить root cause и почему не поймали ранее
3. Добавить лучше тесты
4. Добавить lint rules чтобы не повторилось
5. Обновить документацию

Типичная временная линия

Лучшие практики

1. Пиши тест ДО исправления - TDD подход
2. Делай минимальное изменение - не рефактори весь файл
3. Проверь всё репродуцируется перед тем как начать
4. Code review обязателен для качества
5. Мониторь после deploy - может быть регрессия
6. Документируй root cause - чтобы не повторилось
7. Используй feature flags для risky fixes

Вывод

Процесс исправления бага:

1. Обнаружить и задокументировать
2. Воспроизвести и проанализировать
3. Написать тест (RED)
4. Исправить код (GREEN)
5. Рефакторить (REFACTOR)
6. Code review
7. Deploy
8. Мониторинг
9. Post-mortem если важный

Ключ - TDD: тест ДО кода, и обязательный code review перед merge.