Инженерия деградации: почему сложное ПО неизбежно ломается со временем и что с этим делать

2025-06-15 в 14:15, admin, рубрики: legacy-код, архитектура, баги, инженерия деградации, рефакторинг, системное мышление, старение ПО, техдолг

Долгоживущие программные системы, как и живые организмы, склонны к старению. Эта статья — глубокое техническое исследование закономерностей деградации сложного ПО: от утечек абстракций до архитектурной энтропии. Разберём реальные примеры, редкие баги, системное гниение и последствия спагетти-рефакторинга. Код, хаос и человеческий фактор — всё как мы любим.

Если вы когда-нибудь открывали 10-летний Java-монолит и пытались понять, зачем в середине пайплайна логин-прослойки вызывается System.gc() — поздравляю, вы соприкоснулись с инженерией деградации. Это неофициальный, но абсолютно реальный раздел знаний: как сложные программные системы со временем превращаются в фрактальную кашу из решений, компромиссов и технического долга.

И, что важнее — почему это нормально.

В этой статье речь пойдёт не о багфиксах, CI/CD или микросервисах. Мы копнём глубже. Здесь — история о том, как со временем ломается не просто код, а сама логика, архитектура и даже социальные связи внутри проекта. С примерами, кодом, болью и странным юмором.

Глава 1. Архитектурная энтропия: от А до О, (черт)

Любая достаточно сложная система стремится к беспорядку. Это не метафора, это термодинамика, которую можно наблюдать даже в коде. Пусть у нас есть идеально задокументированная, модульная и покрытая тестами система. Что с ней произойдёт через 5 лет?

Вот типичный сценарий:

Ушли авторы архитектуры.
Появились срочные фичи без времени на рефакторинг.
Прототипы попали в прод.
Починили баг — создали два новых.
Один из разработчиков решил, что DI-контейнер — это зло, и начал руками тащить зависимости.

Результат: архитектурный дрейф. Система больше не соответствует изначальной модели. А новый разработчик вместо «прочитал документацию и начал коммитить» погружается в неделю археологических раскопок.

Вот пример:

// Классический legacy-интерфейс
public interface AuthService {
    boolean isAuthorized(String userId);
    void authenticate(String username, String password);
    void logout();
}

// Через 6 лет...
public class SuperAuthService implements AuthService {
    public boolean isAuthorized(String userId) {
        if (userId == null) return false;
        return userId.startsWith("admin_") || checkLdap(userId);
    }

    public void authenticate(String username, String password) {
        if (username.contains("admin")) {
            callLegacyLogin(username, password);
        } else {
            ldapAuth(username, password);
        }
    }

    public void logout() {
        try {
            legacySessionClear();
        } catch (Exception ignored) {}
    }

    // Частные методы, пришедшие из старого кода
    private void callLegacyLogin(String u, String p) { /* ... */ }
    private void ldapAuth(String u, String p) { /* ... */ }
    private boolean checkLdap(String u) { return true; }
    private void legacySessionClear() { /* ... */ }
}

На первый взгляд — рабочий код. Но здесь нарушено всё: от принципа единой ответственности до здравого смысла. И таких кусков — тысячи.

Глава 2. Спагетти-рефакторинг и микросервисный ад

Иногда команды осознают, что всё плохо. Они зовут архитектора, делают ревью, говорят «перепишем всё на микросервисы». И вот тут начинается новая фаза деградации.

Микросервисы — не панацея. Без культуры и контроля они легко становятся «микрохаосом». Пример из жизни: монолит на Python 2.7, который «разрезали» на 28 сервисов. Итог — 28 сервисов с копипастой, shared-моделью и непонятным API.

Вот типичный «вырезанный» сервис:

# service/user/auth.py
from legacy.session import login as legacy_login

def authenticate(user, password):
    if user.startswith("admin"):
        return legacy_login(user, password)
    else:
        return ldap_auth(user, password)

def ldap_auth(user, password):
    # Вызов LDAP, с обёрткой на случай падения
    try:
        return ldap_lib.authenticate(user, password)
    except Exception as e:
        logger.warning("LDAP fail: %s", str(e))
        return False

Знакомо? Вытащили кусок, не решив корень проблемы.

Глава 3. Технический долг как хроническая болезнь

Интересно, что деградация — это не всегда «сломалось». Это может быть просто ухудшение условий поддержки. Как с автомобилем: ездит, но лампочка «check engine» давно горит.

Главные признаки:

Невозможно обновить зависимости без каскада ошибок.
Любой pull request требует ревью трёх системных старцев.
Сборка требует артефактов, которые никто не может пересоздать.
Любой тестовый деплой вызывает стресс.

Да, такое ПО «работает». Но поддержка становится дорогой, а внедрение новых фич — похожим на минное поле.

Глава 4. Люди как часть проблемы

Нельзя винить только код. Часто именно оргструктура влияет на деградацию. Вспомним закон Конвея: архитектура повторяет коммуникационные связи в компании. Если в компании всё строится на митингах, чатиках и срочных тасках — код будет таким же.

Заключение: принять хаос и жить с ним

Инженерия деградации — не про борьбу с хаосом. Это про осознанное проектирование систем с учётом неизбежного старения. Как врачи не борются со смертью, но умеют продлевать качество жизни — так и инженеры могут строить ПО, которое стареет достойно.

Это значит: