Что такое YAGNI?

Что такое YAGNI

YAGNI (англ. You Aren't Gonna Need It, дословно "Вам это не понадобится") — это ключевой принцип экстремального программирования (XP) и гибкой разработки (Agile), который предписывает разработчикам добавлять функциональность только тогда, когда она действительно необходима, а не потому, что она может понадобиться в будущем.

Суть принципа

Основная идея YAGNI заключается в отказе от преждевременной оптимизации и избыточного проектирования. Разработчик должен сосредоточиться на реализации текущих требований из бэклога продукта или спринта, не тратя время на создание "гибких" или "расширяемых" компонентов "на вырост". Считается, что прогнозы о будущих потребностях часто оказываются ошибочными, а код, написанный "про запас", усложняет систему без реальной отдачи.

Почему YAGNI важен в разработке (особенно под iOS)?

1. Снижение сложности кода. Каждая новая абстракция, интерфейс или условие "на будущее" увеличивает когнитивную нагрузку на команду, затрудняет чтение, тестирование и рефакторинг кода.
2. Экономия времени и ресурсов. Время, потраченное на реализацию невостребованной функциональности, — это время, отнятое у реализации реально нужных фич, исправления багов или улучшения архитектуры существующего кода.
3. Большая гибкость. Когда приходит время добавлять реально нужную функциональность, требования и контекст могут измениться. Код, написанный "на будущее", часто оказывается не в той форме, какая требуется, и его всё равно приходится переделывать. Более выгодно иметь простую, понятную кодобазу, которую можно легко модифицировать.
4. Упрощение поддержки. Меньше кода — меньше потенциальных мест для багов. Неиспользуемые пути выполнения в коде ("dead code") могут вводить в заблуждение других разработчиков и становятся обузой при рефакторинге.

Пример нарушения и следования YAGNI в Swift

Нарушение YAGNI (преждевременная абстракция): Допустим, нам нужно отобразить список пользователей, и мы предполагаем, что в будущем понадобится отображать список продуктов. Мы сразу создаем общий абстрактный сервис.

// Ненужная на текущий момент абстракция
protocol DataFetcher {
    associatedtype Model
    func fetchData(completion: @escaping ([Model]) -> Void)
}

class UserFetcher: DataFetcher {
    typealias Model = User

    func fetchData(completion: @escaping ([User]) -> Void) {
        // Запрос к сети или базе данных
        let users = [User(name: "Alice"), User(name: "Bob")]
        completion(users)
    }
}

// Вью-контроллер уже зависит от сложной абстракции
class UserViewController: UIViewController {
    let fetcher = UserFetcher()
    // ... логика отображения
}

Следование YAGNI: Мы реализуем только то, что нужно прямо сейчас — получить и показать пользователей. Код прост и решает конкретную задачу.

struct User {
    let name: String
}

class UserService {
    func fetchUsers(completion: @escaping ([User]) -> Void) {
        // Прямой и понятный запрос за пользователями
        let users = [User(name: "Alice"), User(name: "Bob")]
        completion(users)
    }
}

class UserViewController: UIViewController {
    let service = UserService()
    // ... логика отображения
}

Когда позже действительно понадобится получать продукты, мы сможем оценить, есть ли реальное сходство в логике, и, при необходимости, аккуратно выделить общую часть через рефакторинг. К этому моменту мы будем точно понимать требования к обоим сервисам.

Как применять YAGNI на практике в iOS-разработке?

• Фокусируйтесь на User Story текущего спринта. Реализуйте фичи ровно в том объёме, который описан в критериях приемки.
• Рефакторите "по запаху". Не создавайте абстракции заранее. Сначала напишите конкретный код. Если позже вы заметите дублирование или потребность в изменении (этот "запах" кода), тогда и проводите рефакторинг, извлекая общую логику. Это основа принципа "Трёх ударов" (Rule of Three).
• Используйте простые структуры данных. Не создавайте сложные иерархии классов "на всякий случай". Начинайте с struct в Swift, переходите к классам и протоколам только тогда, когда их преимущества (например, ссылочная семантика или полиморфизм) станут явно необходимы.
• Избегайте "свитчей" от дьявола. Не добавляйте switch или if-else с зарезервированными кейсами для гипотетических будущих состояний.

Границы применения YAGNI

YAGNI не означает, что нужно писать плохой, не поддерживаемый код. Он борется с избыточностью, а не с качеством. Принципы SOLID, DRY и написание покрытых тестами кода остаются важными. YAGNI напоминает нам, что внедрение этих принципов должно быть своевременным и обоснованным реальными, а не гипотетическими потребностями.

Итог: YAGNI — это философия бережливого программирования. Она учит нас быть прагматичными, доверять рефакторингу как инструменту и постоянно спрашивать себя: "Действительно ли эта функциональность нужна прямо сейчас, или я добавляю её из-за возможного, но не гарантированного сценария?". Следование этому принципу ведёт к созданию более простых, чистых и адаптивных iOS-приложений.