Что будешь делать на старте работы с легаси-кодом?

Работа с Legacy-кодом: мой подход

Работа с legacy кодом — это одна из самых частых задач в реальной разработке. Я разработал системный подход для такой работы.

Этап 1: Анализ и Понимание (неделя 1)

Что я делаю:

1. Документирование текущего состояния

   • Читаю существующую документацию (если есть)
   • Понимаю архитектуру проекта
   • Инвентаризирую основные модули
   • Чиню техдолг список

2. Запуск проекта локально

   • Клонирую репозиторий
   • Настраиваю окружение
   • Запускаю existing tests
   • Запускаю приложение, видю как оно работает

3. Читаю важные части кода

   • Точка входа (index.php, routing)
   • Основные бизнес-логика
   • Интеграции с внешними сервисами
   • Критичные функции для безопасности

4. Общение с командой

   • Спрашиваю у того, кто писал/поддерживал код
   • Узнаю историю проекта
   • Понимаю что планировалось, но не реализовано
   • Выясняю самые болезненные места

Этап 2: Оценка (неделя 2)

Создаю отчёт с приоритизацией:

# Legacy Code Assessment

## Критичные проблемы (Блокеры)
- Security уязвимости (SQL injection, XSS, CSRF)
- Performance проблемы (N+1 запросы, медленные endpoints)
- Нестабильность (частые crashes, memory leaks)
- Потеря данных

## Важные проблемы (Спринты 1-3)
- Отсутствие тестов
- Плохая документация
- Технический долг
- Code duplication

## Можно отложить (На потом)
- Рефакторинг красоты
- Переписывание работающих функций
- Миграции на новые версии (если текущие работают)

Этап 3: Сначала - Стабильность

Не рефакторю сразу! Сначала делаю:

1. Добавляю тесты для критичного кода

   // Пишу тесты для существующего функционала
   // Это позволит обнаружить баги и не сломать во время рефакторинга
   
   public function test_payment_processing_with_valid_card() {
       $result = (new PaymentService())->process($validCard, 100);
       $this->assertEquals('success', $result['status']);
   }
   

2. Исправляю критичные security баги

   • SQL injections
   • XSS уязвимости
   • CSRF атаки
   • Hardcoded passwords

3. Оптимизирую явные performance проблемы

   • N+1 запросы в БД
   • Неиспользуемые запросы
   • Медленные endpoints

Этап 4: Документирование

Создаю документацию по ходу понимания:

# Project Architecture

## Database
- MySQL 5.7
- Main tables: users, orders, products
- No migrations (manual updates)

## API Endpoints
GET /api/users/{id} - получить пользователя (устарело, не использовать)
GET /api/v2/users/{id} - новый endpoint

## Known Issues
1. Payment processing sometimes fails (investigate async issues)
2. Reports generation too slow (needs indexing)
3. Email notifications not sent reliably

Этап 5: Postepенный Рефакторинг

Принцип: Boy Scout Rule (оставляй код чище, чем нашёл)

// ❌ Не делаю полный рефакторинг сразу
// Не переписываю весь код в один коммит

// ✅ Делаю маленькие улучшения
function getUserWithOrders($userId) {
    $user = User::find($userId);
    
    // Сначала добавлю тест
    // Потом отрефакторю с использованием Eloquent relationships
    // Результат: User::with('orders')->find($userId)
    
    // Маленький шаг за шагом, каждый шаг протестирован
}

Приоритет рефакторинга:

1. Код, который часто меняется
2. Код, который читают многие
3. Критичный бизнес-код
4. Код с bugs (во время исправления bug фиксим и style)

Этап 6: Инструменты и Автоматизация

Внедряю постепенно:

# 1. Static analysis
composer require phpstan/phpstan --dev
phpstan analyse src/

# 2. Code style
composer require squizlabs/php_codesniffer --dev
phpcbf src/ # Auto-fix

# 3. Testing
composer require phpunit/phpunit --dev
phpunit

# 4. CI/CD
# Добавляю GitHub Actions / GitLab CI
# Тесты должны пройти перед merge

Этап 7: План на долгосрок

Создаю Roadmap рефакторинга:

Q1 2024:
- Написать тесты для payment module
- Исправить SQL injection уязвимости
- Оптимизировать slow queries

Q2 2024:
- Перейти на Laravel 10 (или стоит ждать?)
- Разделить на микросервисы (если нужно)
- Добавить proper logging

Q3 2024:
- Переписать legacy authentication
- Обновить dependencies

Основные принципы

1. Не ломать — первая задача это стабильность
2. Тесты первыми — перед любым изменением
3. Маленькие шаги — не переписывать всё за раз
4. Документировать — помогает себе и команде
5. Обсуждать — легаси код часто имеет причины быть таким
6. Метрики — отслеживаю улучшения (тесты, производительность)

Чего избегаю

• Переписывания кода, который работает
• Добавления новых dependencies без необходимости
• Рефакторинга без тестов
• Больших PR'ов (hard to review)
• Удаления кода "потому что он плохо написан"
• Игнорирования причин, почему код такой