YAGNI - Вам это не понадобится

YAGNI (You Aren't Gonna Need It) - Вам это не понадобится

Описание принципа

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

Применение

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

Пример

// Плохо: добавление ненужной сейчас функциональности
Процедура СохранитьКлиента(Клиент)
    // Основная логика сохранения...
    
    // Излишняя функциональность, которая сейчас не нужна
    ОтправитьУведомлениеВМессенджеры(Клиент);
    ПодготовитьДанныеДляРассылки(Клиент);
    СформироватьОтчетПоВзаимодействиям(Клиент);
КонецПроцедуры;

// Хорошо: только необходимая сейчас функциональность
Процедура СохранитьКлиента(Клиент)
    // Основная логика сохранения...
КонецПроцедуры;

Важно

Следование принципу YAGNI позволяет:

• Сократить время разработки
• Упростить тестирование
• Сфокусироваться на действительно необходимом функционале
• Избежать ненужного усложнения кода

Рекомендации

1. Проектируйте итеративно - начинайте с минимально необходимого функционала и расширяйте его по мере необходимости.

2. Следуйте требованиям заказчика - реализуйте только то, что было согласовано, и не добавляйте лишнего.

3. Сохраняйте простоту структуры метаданных - добавляйте только те объекты метаданных (реквизиты, табличные части, регистры и т.д.), которые необходимы для текущей функциональности.

4. Используйте гибкую архитектуру - проектируйте систему так, чтобы её можно было легко расширить, когда потребуется новая функциональность.

Типичные проблемы при применении

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

Баланс между YAGNI и перспективным планированием

Важно найти баланс между слепым следованием YAGNI и разумным планированием архитектуры. Если функциональность точно понадобится в ближайшем будущем и её добавление сейчас существенно сэкономит ресурсы, имеет смысл реализовать её заранее.

Используйте следующие критерии для принятия решения:

• Насколько уверенно мы знаем, что функциональность понадобится?
• Насколько сложно будет добавить функциональность позже?
• Какова стоимость добавления функциональности сейчас по сравнению с добавлением её позже?

Предостережение

Важно различать "инфраструктурную" подготовку и избыточную функциональность. Создание гибкой архитектуры не противоречит YAGNI, а вот добавление конкретных функций "на всякий случай" - противоречит.