157 lines
18 KiB
Markdown
157 lines
18 KiB
Markdown
---
|
||
sidebar_position: 8
|
||
---
|
||
|
||
# Принципы разработки
|
||
|
||
## 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/](https://habr.com/ru/companies/itelma/articles/546372/)
|