132 lines
14 KiB
Markdown
132 lines
14 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 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.\
|
||
Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.\
|
||
Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.
|
||
|
||
🚀 **_Источник: DeepSeek_**
|
||
dДополнительный источник: [https://habr.com/ru/companies/itelma/articles/546372/](https://habr.com/ru/companies/itelma/articles/546372/)
|