Какой принцип SOLID чаще всего нарушаешь?

# Какой принцип SOLID чаще всего нарушаешь

Это отличный вопрос, потому что он заставляет быть честным. И я не буду притворяться, что идеален.

Главный нарушитель — SRP (Single Responsibility Principle)

У меня есть тенденция нарушать Single Responsibility в спешке. Не потому что я не знаю про SOLID, а потому что в реальных проектах есть давление deadlines.

Типичный сценарий:

// Начало спринта — всё хорошо
public class PlayerController : MonoBehaviour {
    private PlayerMovement movement;
    private PlayerCombat combat;
    // Разделено правильно
}

// Спринт идёт, deadline приближается
public class PlayerController : MonoBehaviour {
    public void Update() {
        HandleMovement();
        HandleCombat();
        UpdateUI();          // Начинаю добавлять UI сюда
        CheckQuestProgress(); // И логику квестов
        PlayAudio();         // И звуки
        // Класс разросся до 500 строк...
    }
}

Это обычно происходит, когда:

• Быстро нужен прототип
• Требования меняются в процессе
• Изначально я неправильно оценил сложность

Второй нарушитель — DIP (Dependency Inversion)

Когда время поджимает, создаю hardcoded зависимости вместо инъекции:

// Быстрое решение — нарушает DIP
public class AudioManager : MonoBehaviour {
    private static AudioManager instance;
    
    public static void PlaySound(string sound) {
        instance.audioSource.PlayOneShot(audioClips[sound]);
    }
}

// Потом в другом месте
public class Player {
    public void TakeDamage() {
        AudioManager.PlaySound("damage"); // Hardcoded зависимость
    }
}

// Сложно тестировать, сложно мокировать...

Почему это происходит

Я не буду делать вид, что это просто лень. Это:

1. Real-world constraints — deadline, scope, ограниченные ресурсы
2. Over-engineering в начале — иногда SOLID на ранних стадиях замедляет
3. Неправильная оценка — изначально казалось просто, потом раскрылось
4. Pressure — когда на тебе три проекта и сроки горят

Как я это исправляю

Техники, которые помогают:

1. Refactor phase — выделяю время после спринта на рефакторинг
2. Code review — коллеги ловят нарушения
3. TDD подход — когда пишу тесты первыми, архитектура получается лучше
4. Техдолг tracking — отмечаю в Jira места, которые нужно переделать

// Пример правильного рефакторинга

// До — монолит
public class PlayerController : MonoBehaviour {
    public void Update() { /* 500 строк */ }
}

// После — разделено правильно
public class PlayerController : MonoBehaviour {
    private IMovementSystem movement;
    private ICombatSystem combat;
    private IUISystem ui;
    
    public PlayerController(
        IMovementSystem movement,
        ICombatSystem combat,
        IUISystem ui
    ) {
        this.movement = movement;
        this.combat = combat;
        this.ui = ui;
    }
    
    public void Update() {
        movement.Update();
        combat.Update();
        ui.Update();
    }
}

Мой подход к SOLID

Я считаю, что SOLID — это not absolutist rules, а guidelines:

• На ранних стадиях прототипа может быть нарушение SRP в порядке вещей
• Но когда код стабилизируется, нужен рефакторинг
• Тесты подсказывают, когда архитектура неправильная
• Лучше "грязный" работающий код, чем идеальная архитектура, которая никогда не выпустится

Но есть красная линия: если я вижу, что код становится unmaintainable, я всегда отстаиваю время на рефакторинг. Потому что tech debt растёт экспоненциально, а исправляют его линейно.

Такой баланс — это как раз то, чему я научился за 10+ лет: идеализм SOLID vs pragmatism реального проекта.