Что такое YAGNI (вам это не понадобится)

Определение

YAGNI пришел из экстремального программирования (Extreme Programming). Мартин Фаулер (Martin Fowler) возводит термин к раннему разговору Кента Бека (Kent Beck) и Чета Хендриксона (Chet Hendrickson) в проекте C3. Правило такое: не создавать возможность ради функции, которая, как вы только предполагаете, понадобится. Фаулер называет четыре цены такой предполагаемой функции. Цена создания это усилия на анализ, программирование и тестирование. Цена задержки это полезная функция, которую за это время не сделали. Цена содержания это сложность, которую функция добавляет и из-за которой труднее менять все остальное. Цена исправления наступает, когда приходит настоящая потребность и оказывается, что функция сделана не так. У правила есть граница: Фаулер прямо пишет, что оно не относится к усилиям, которые упрощают изменение программы. Держать работу легкой для изменений не значит делать функцию на догадке.

Почему это важно

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

Напрямую связано: Содержание проекта (Scope), Agile (гибкий подход), Технический долг (Technical Debt).

Советы по улучшению

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

Частые ошибки

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