Принцип программирования YAGNI — «Вам это не понадобится»

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

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

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

«Бесплатных» функций в программных продуктах просто не бывает. Если рассматривать материальную сторону, то любые ненужные, но фактически реализованные «фичи» оплачиваются либо заказчиком (в бюджет закладываются расходы на те функции, которые не нужны), либо исполнителем из прибыли по проекту. И тот, и другой варианты с точки зрения бизнеса неверны. Если же говорить о нематериальных затратах, то любые «бонусные» возможности усложняют сопровождение, увеличивают вероятность ошибок и усложняют взаимодействие с продуктом, — между объёмом кодовой базы и описанными характеристиками есть прямая зависимость. Больше написанного кода — труднее сопровождать и выше вероятность появления «багов», тут очень уместна поговорка: «лучший код — это ненаписанный код».

Принципы YAGNI и KISS очень похожи, если KISS нацелен на упрощение и полезен в плане работы с теми требованиями, которые имеют место быть, то YAGNI более категоричен и применяется для ограждения проектов по разработке ПО от «размывания» их рамок.

Разработка минимально ценного (или жизнеспособного) продукта (MVP) и принципы Agile тоже очень сильно перекликаются с подходом YAGNI.

В принципе, подход к реализации проектов строго по ТЗ бывает верен с нескольких ракурсов: заказчик не должен платить за то, что ему не надо, а продукт должен быть максимально сопровождаем и его качество не должно страдать от реализации ненужных функций.

YAGNI нормально работает только без фанатизма и догматизма.

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

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

Обычно целесообразно писать код для текущих задач, а не гипотетических сценариев. Разумеется, что это не оправдание для халтуры, а полезный инструмент для борьбы с переусложнением и овер‑инженерингов. Закончить же эту статью хочется процитировав Кента Бека, создателя методологий экстремального программирования (XP) и разработки через тестирование (TDD) : «Мы будем тщательно формировать решение сегодняшней проблемы именно сегодня в надежде на то, что мы всегда сможем решить завтрашнюю проблему завтра».

методологии разработкивеб-разработкабэкендфронтенд
Статья опубликована в 2019 и была обновлена в 2025 году

Тематические статьи

Принцип программирования KISS — делайте вещи проще

KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.

Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.

Статья обновлена в 2025 году
Принцип программирования DRY — don’t repeat yourself / не повторяйтесь

Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.

Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.

Статья обновлена в 2025 году
Стандарты кодирования — залог хорошей сопровождаемости проекта

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

Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.

Статья обновлена в 2023 году
SOLID — принципы объектно-ориентированного программирования

SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, предложенных Робертом Мартином:

  • Single responsibility — принцип единственной ответственности
  • Open-closed — принцип открытости / закрытости
  • Liskov substitution — принцип подстановки Барбары Лисков
  • Interface segregation — принцип разделения интерфейса
  • Dependency inversion — принцип инверсии зависимостей
Статья обновлена в 2025 году
TDD — разработка через тестирование

TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов. При следовании этой методологии тесты пишутся до написания кода.

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

Статья обновлена в 2025 году

Наши услуги

Цифровизация

Формализуем и автоматизируем бизнес‑процессы, осуществляем системную интеграцию, разрабатываем и внедряем цифровые решения, повышающие эффективность бизнеса.

Разработка

Разрабатываем сложные веб‑приложения и сайты. Создаём как отдельные инструменты для бизнеса, так и полноценные цифровые системы по индивидуальным требованиям.

Разработка корпоративных информационных систем

Cоздаём как комплексные ERP‑системы для бизнеса, так и более специализированные информационные системы — CRM, WMS, BPMS, экспертные и аналитические системы, системы поддержки принятия решений, коммуникативные сервисы и многое другое.

Поддержка проектов и DevOps

Осуществляем комплексную поддержку ИТ‑проектов для обеспечения высокой работоспособности и улучшения продуктовых метрик.

Отказоустойчивость

Разрабатываем и сопровождаем комплексные системы, устойчивые к отказу оборудования, отдельных сервисов и целых подсистем.

Быстродействие

Разрабатываем веб‑приложения, работающие по‑настоящему быстро: генерация страниц осуществляется за доли секунды, а загрузка сайта даже на медленных каналах занимает не более пары секунд.

Высокие нагрузки

Мы создаём сайты и веб‑приложения, которые выдерживают десятки тысяч обращений в минуту без сбоев и без снижения скорости работы.