Yagni программирование принцип программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SOLID — принципы объектно‑ориентированного программирования

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

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

БЭМ и независимые блоки

Вёрстка независимыми блоками — это методология, которая была сформулирована Виталием Харисовым из компании Яндекс. Впоследствии эта методология была расширена и получила название БЭМ (Блок-Элемент-Модификатор). Собственно БЭМ нужен для упрощения командной разработки, для унификации интерфейсов и для более активного повторного использования программного кода.

REST и RESTful — передача репрезентативного состояния и ресурсный роутинг

REST — это стиль построения архитектуры распределенного клиент‑серверного приложения, который упрощает роутинг и построение API.

Принципы SOLID: принцип единственной ответственности

Принцип единственной ответственности — один из пяти основных принципов объектно‑ориентированного программирования и проектирования, сформулированных Робертом Мартином.

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

Принципы SOLID: принцип открытости-закрытости

Принцип открытости/закрытости — один из пяти основных принципов объектно‑ориентированного программирования и проектирования, сформулированных Робертом Мартином.

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

Принципы SOLID: принцип разделения интерфейса

Принцип разделения интерфейса — один из пяти основных принципов объектно‑ориентированного программирования и проектирования, сформулированных Робертом Мартином.

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

Источник