Cледование данному принципу заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. Это позволяет вести разработку, руководствуясь экономическими критериями: заказчик не должен оплачивать ненужные ему функции, а разработчики не должны тратить своё оплачиваемое время на реализацию того, что не требуется.
Основная проблема, которую решает принцип YAGNI — это устранение тяги программистов к излишней абстракции, к экспериментам «из интереса» и к реализации функций, которые сейчас не нужны, но, по мнению разработчика, могут вскоре понадобиться или просто будут полезны, хотя в реальности такого часто не происходит.
YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
«Бесплатных» функций в программных продуктах просто не бывает. Если рассматривать материальную сторону, то любые ненужные, но фактически реализованные «фичи» оплачиваются либо заказчиком (в бюджет закладываются расходы на те функции, которые не нужны), либо исполнителем из прибыли по проекту. И тот, и другой варианты с точки зрения бизнеса неверны. Если же говорить о нематериальных затратах, то любые «бонусные» возможности усложняют сопровождение, увеличивают вероятность ошибок и усложняют взаимодействие с продуктом, — между объёмом кодовой базы и описанными характеристиками есть прямая зависимость. Больше написанного кода — труднее сопровождать и выше вероятность появления «багов», тут очень уместна поговорка: «лучший код — это ненаписанный код».
Принципы YAGNI и KISS очень похожи, если KISS нацелен на упрощение и полезен в плане работы с теми требованиями, которые имеют место быть, то YAGNI более категоричен и применяется для ограждения проектов по разработке ПО от «размывания» их рамок.
Разработка минимально ценного (или жизнеспособного) продукта (MVP) и принципы Agile тоже очень сильно перекликаются с подходом YAGNI.
В принципе, подход к реализации проектов строго по ТЗ бывает верен с нескольких ракурсов: заказчик не должен платить за то, что ему не надо, а продукт должен быть максимально сопровождаем и его качество не должно страдать от реализации ненужных функций.
YAGNI нормально работает только без фанатизма и догматизма.
Экономия ресурсов, простота поддержки, гибкость архитектуры — это то, что может дать следование принципу YAGNI. Однако, стоит учесть и потенциальный вред от данного подхода.
В проектах с высокими требованиями к безопасности необходимы как предварительное проектирование, так и более глубокое осмысление архитектуры. Некоторые архитектурные решения будет сложно изменить со временем, здесь YAGNI стоит применять с особой осторожностью. Если проект — это не прототип и есть высокие перспективы его развития в будущем, то вполне разумно изначально задумываться о расширяемости и масштабируемости.
Обычно целесообразно писать код для текущих задач, а не гипотетических сценариев. Разумеется, что это не оправдание для халтуры, а полезный инструмент для борьбы с переусложнением и овер‑инженерингов. Закончить же эту статью хочется процитировав Кента Бека, создателя методологий экстремального программирования (XP) и разработки через тестирование (TDD) : «Мы будем тщательно формировать решение сегодняшней проблемы именно сегодня в надежде на то, что мы всегда сможем решить завтрашнюю проблему завтра».
