Skip to main content

Принципы разработки

YAGNI​

You Aren’t Gonna Need It / Вам это не понадобится

Принцип YAGNI (англ. You Aren’t Gonna Need It — «Вам это не понадобится») — это концепция из методологии разработки программного обеспечения, которая гласит, что не следует добавлять функциональность в код до тех пор, пока она действительно не потребуется. Этот принцип является частью экстремального программирования (XP) и тесно связан с другими принципами, такими как KISS (Keep It Simple, Stupid) и DRY (Don’t Repeat Yourself).

Основные идеи YAGNI:​

  1. Избегание преждевременной оптимизации:
    • Не стоит тратить время на написание кода, который, возможно, никогда не будет использован.
    • Это помогает избежать усложнения системы и снижает вероятность внесения ошибок.
  2. Фокус на текущих требованиях:
    • Разработчики должны сосредоточиться на реализации только тех функций, которые необходимы прямо сейчас.
    • Это позволяет быстрее выпускать рабочие версии продукта и получать обратную связь от пользователей.
  3. Упрощение кода:
    • YAGNI способствует написанию более простого и понятного кода, так как в нем отсутствуют лишние элементы.
    • Это облегчает поддержку и модификацию кода в будущем.
  4. Экономия времени и ресурсов:
    • Не нужно тратить время на разработку и тестирование функциональности, которая может оказаться ненужной.
    • Это позволяет сосредоточиться на действительно важных задачах.

Преимущества YAGNI:​

  • Снижение сложности кода.
  • Уменьшение времени на разработку.
  • Более гибкая реакция на изменения требований.
  • Упрощение тестирования и поддержки.

Когда YAGNI не применим:​

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

Дополнительно​

Этот принцип прост и очевиден, но ему далеко не все следуют. Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже.
Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.
Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.

DRY​

Don’t Repeat Yourself / Не повторяйтесь

Принцип DRY (англ. Don’t Repeat Yourself — «Не повторяйся») — это один из ключевых принципов разработки программного обеспечения, который направлен на минимизацию дублирования кода. Основная идея заключается в том, что каждая часть знания или логики в системе должна иметь единственное, однозначное и авторитетное представление в коде.

Основные идеи DRY:​

  1. Устранение дублирования:
    • Если один и тот же код или логика повторяются в нескольких местах, это увеличивает сложность поддержки и повышает риск ошибок.
    • Вместо этого следует выносить повторяющийся код в отдельные функции, модули или классы.
  2. Единая точка изменения:
    • Если логика должна быть изменена, это нужно сделать только в одном месте, а не во всех местах, где она используется.
    • Это упрощает поддержку и снижает вероятность ошибок.
  3. Повышение читаемости и поддерживаемости:
    • Код становится более компактным и понятным, так как логика не размазана по всей кодовой базе.

Преимущества DRY:​

  1. Снижение ошибок:
    • Меньше вероятность того, что изменения в логике будут внесены только в одном месте, а в других — забыты.
  2. Упрощение поддержки:
    • Легче вносить изменения, так как логика сосредоточена в одном месте.
  3. Улучшение читаемости:
    • Код становится более структурированным и понятным.
  4. Экономия времени:
    • Не нужно копировать и вставлять код, а также тестировать его в нескольких местах.

Когда DRY не следует применять слепо:​

  1. Избыточная абстракция:
    • Иногда попытка устранить дублирование может привести к созданию сложных и ненужных абстракций, которые усложняют понимание кода.
  2. Микрооптимизации:
    • Не стоит применять DRY для устранения дублирования, если это незначительные фрагменты кода, которые вряд ли будут изменяться.
  3. Разные контексты:
    • Если дублирующийся код используется в разных контекстах и может изменяться независимо, то его объединение может привести к проблемам.

Связь с другими принципами:​

  • KISS (Keep It Simple, Stupid): DRY помогает упрощать код, устраняя ненужное дублирование.
  • YAGNI (You Aren’t Gonna Need It): DRY не следует применять для создания абстракций, которые могут понадобиться в будущем, но не нужны сейчас.

Дополнительно​

Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру».
Идея вращается вокруг единого источника правды (single source of truth — SSOT). Что это вообще такое?
Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом.
В большинстве случаев дублирование кода происходит из-за незнания системы. Прежде чем что-либо писать, проявите прагматизм: осмотритесь. Возможно, эта функция где-то реализована. Возможно, эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.

KISS​

Keep It Simple, Stupid / Будь проще

Принцип KISS (англ. Keep It Simple, Stupid — «Делай проще, тупица») — это концепция в разработке программного обеспечения, которая подчеркивает важность простоты и минимализма в проектировании и реализации систем. Основная идея заключается в том, что простые решения чаще всего являются лучшими, так как их легче понимать, поддерживать и модифицировать.

Основные идеи KISS:​

  1. Упрощение кода:
    • Код должен быть настолько простым, насколько это возможно, но не проще.
    • Сложные конструкции и избыточные абстракции следует избегать.
  2. Минимизация сложности:
    • Чем проще система, тем меньше вероятность возникновения ошибок и тем легче её поддерживать.
    • Простота также облегчает понимание кода новыми разработчиками.
  3. Фокус на решении задачи:
    • Не стоит добавлять функциональность, которая не требуется для решения текущей задачи.
    • Это связано с принципом YAGNI (You Aren’t Gonna Need It).
  4. Избегание «умного» кода:
    • Код, который выглядит «умным» (например, с использованием сложных языковых конструкций или оптимизаций), часто сложен для понимания и поддержки.
    • Лучше писать код, который легко читать и понимать.

Преимущества KISS:​

  1. Упрощение поддержки:
    • Простой код легче понимать и изменять, что снижает затраты на поддержку.
    • Снижение вероятности ошибок:
    • Чем меньше сложность, тем меньше вероятность допустить ошибку.
  2. Ускорение разработки:
    • Простые решения быстрее реализуются и тестируются.
  3. Улучшение читаемости:
    • Код становится более понятным для других разработчиков, что особенно важно в командной работе.

Когда KISS не следует применять слепо:​

  1. Оптимизация производительности:
    • Иногда для достижения необходимой производительности требуется более сложный код.
    • Однако даже в таких случаях следует стремиться к балансу между простотой и эффективностью.
  2. Специфические требования:
    • В некоторых случаях сложные решения могут быть оправданы, если они соответствуют бизнес-требованиям или ограничениям системы.

Связь с другими принципами:​

  • YAGNI (You Aren’t Gonna Need It): KISS поддерживает идею о том, что не следует добавлять ненужную функциональность.
  • DRY (Don’t Repeat Yourself): KISS помогает избегать избыточного дублирования, но не за счет усложнения кода.
  • SOLID: KISS дополняет принципы SOLID, делая акцент на простоте и ясности кода.

Дополнительно​

Этот принцип был разработан ВМС США в 1960 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.
Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.
Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.

SOLID​

Принципы SOLID — это набор из пяти ключевых принципов объектно-ориентированного программирования и проектирования, которые помогают создавать гибкие, поддерживаемые и масштабируемые программные системы. Аббревиатура SOLID была введена Робертом Мартином (известным также как Uncle Bob) и расшифровывается следующим образом:

Simple responsibility principle (принцип единой ответственности)​

У класса должна быть только одна причина для изменения, то есть у него должна быть только одна ответственность или работа. Этот принцип помогает сделать занятия более целенаправленными, более понятными и менее подверженными ошибкам.

Open – Closed Principle (Принцип открытости/закрытости)​

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

Liskov Substitution principe (принцип замены Лискова)​

Объекты суперкласса должны быть заменяемы объектами его подклассов без нарушения корректности программы. Другими словами, подклассы должны иметь возможность заменять свои базовые классы без возникновения ошибок.

Interface segregation principle (Принцип разделения интерфейсов)​

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

Dependency inversion principle (Инверсия зависимости)​

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

Преимущества SOLID:​

  1. Гибкость: Код становится проще расширять и модифицировать.
  2. Поддерживаемость: Упрощается понимание и исправление ошибок.
  3. Тестируемость: Код, соответствующий SOLID, легче тестировать.
  4. Масштабируемость: Система становится более устойчивой к изменениям и росту.

🚀 Источник: DeepSeek dДополнительный источник: https://habr.com/ru/companies/itelma/articles/546372/