Легаси

TL;DR

Легаси (legacy code) — устаревший или плохо структурированный код, который трудно поддерживать и изменять, но нельзя просто заменить. Часто характеризуется отсутствием тестов, запутанной структурой и устаревшими зависимостями.

Краткое определение

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

Оригинал и перевод

• Язык: английский
• Оригинал: Legacy (от лат. legatum — завещание, наследство)
• Буквальный перевод: наследие
• Русские аналоги: устаревший код, техническое наследие, старый код

Синонимы и варианты написания

• Legacy code
• Legacy-система
• Устаревший код
• Техническое наследие
• «Код, который лучше не трогать»

Признаки легаси-кода

Легаси определяется не возрастом, а характеристиками:

• ❌ Нет тестов — нельзя проверить, что изменения не сломали систему
• ❌ Нет документации — никто не помнит, почему принято то или иное решение
• ❌ Запутанная структура — логика размазана по файлам, дублирование кода
• ❌ Устаревшие зависимости — PHP 5.6, jQuery 2.x, библиотеки без поддержки
• ❌ «Магические числа» — значения без пояснений (if ($status == 7))
• ❌ Прямые правки в ядре — изменения в штатных файлах CMS/фреймворка
• ❌ Один файл на всё — гигантский init.php с обработчиками, хелперами и логикой

Где встречается

• Старые проекты на Bitrix — /bitrix/modules/, /bitrix/templates/ с прямыми правками
• WordPress проекты — кастомные темы без разделения логики и представления
• Корпоративные системы — внутренние CRM, ERP, написанные 5-10 лет назад
• Самописные CMS — системы, созданные до появления современных фреймворков
• Миграции с устаревших технологий — PHP 4 → PHP 8, jQuery → React

Когда это важно

Легаси становится проблемой в следующих сценариях:

• Новый разработчик в проекте — онбординг занимает недели вместо дней
• Необходимость новых фич — каждое изменение требует рефакторинга
• Баги и уязвимости — страшно трогать, потому что может сломаться всё
• Миграция на новые технологии — старое мешает внедрению нового

Стратегии работы с легаси

1. Рефакторинг (постепенный)

Вынос логики в отдельные модули, автозагрузку, разделение ответственности:

// ❌ Было: всё в одном файле
// /local/php_interface/init.php
include($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/iblock/iblock.php');
function getOrders() { /* 200 строк кода */ }
function sendEmail() { /* 150 строк */ }
// ...

// ✅ Стало: разделение по модулям
// /local/modules/orders/lib/OrderService.php
namespace Orders;
class OrderService {
    public function getOrders(): array { /* ... */ }
    public function sendEmail(): void { /* ... */ }
}

2. Strangler Fig Pattern (удушающий фикус)

Постепенная замена старого кода новым без остановки системы:

Старая система
    ↓
Новый модуль (перенаправление части запросов)
    ↓
Ещё один новый модуль
    ↓
Старая система почти не используется
    ↓
Отключение старой системы ✅

3. Обёртки (Wrappers)

Создание современного API вокруг старого кода:

// Обёртка для старого легаси-класса
class LegacyOrderWrapper implements OrderInterface {
    private $legacyOrder;
    
    public function __construct() {
        $this->legacyOrder = new CLegacyOrder();  // Старый класс
    }
    
    public function create(array $data): int {
        // Адаптация нового интерфейса к старому
        return $this->legacyOrder->Add($data);
    }
}

4. Покрытие тестами

Перед изменениями — покрытие критичного кода тестами:

// PHPUnit тест для легаси-функции
public function testGetOrdersReturnsActiveOrders(): void {
    $orders = getOrders(['status' => 'active']);
    
    $this->assertNotEmpty($orders);
    foreach ($orders as $order) {
        $this->assertEquals('active', $order['STATUS']);
    }
}

Типичные ошибки при работе с легаси

• ❌ Полная переписывание с нуля — долго, дорого, рискованно
• ❌ Остановка разработки на время рефакторинга — бизнес теряет деньги
• ❌ Отсутствие тестов перед изменениями — невозможно проверить результат
• ❌ Эмоциональное отношение — «этот код написал я, он хороший» (нет)
• ❌ Игнорирование легаси — проблема не исчезнет сама собой

Аналоги и связанные термины

• Technical debt — технический долг (более широкое понятие)
• Refactoring — рефакторинг (процесс улучшения)
• Migration — миграция на новые технологии
• Antipattern — антипаттерн (типовая ошибка проектирования)
• Code smell — «запах кода» (признак проблем)

Смотри также (статьи на сайте)

• Структура проекта Bitrix: local folder — организация кода в /local
• Простой модуль Bitrix с компонентом — создание модуля
• PHP 8.3-8.4: типизация и паттерны — модернизация кода

Смотри также (сниппеты)

• local/constants.php: константы — вынос констант
• local/init.php: загрузчик — точка входа
• local/autoload.php: автозагрузка — PSR-4 автозагрузка

Смотри также (термины)

• Refactoring — улучшение структуры кода
• Technical debt — технический долг
• Onboarding — введение в проект
• Antipattern — антипаттерны

Мини-FAQ

Легаси и технический долг — одно и то же?

Ответ: Технический долг — более широкое понятие. Легаси — это результат накопленного техдолга: код, который стал проблемой из-за времени, изменений и отсутствия поддержки.

Можно ли полностью избавиться от легаси?

Ответ: Нет. Любой современный код через 3-5 лет станет легаси. Важно не допускать критического уровня и постепенно рефакторить.

Когда стоит переписать с нуля?

Ответ: Только если:

• Система критически устарела (технологии без поддержки)
• Стоимость поддержки > стоимости разработки новой
• Есть ресурсы на параллельную разработку и поддержку

Как убедить менеджмент в необходимости рефакторинга?

Ответ: Говорить на языке бизнеса:

• «Сейчас фича делается 5 дней, после рефакторинга — 1 день»
• «Каждый месяц 20 часов тратится на баги, которые не появятся после рефакторинга»
• «Риск простоя системы 4 часа при сбое vs 30 минут после»