refactor: move big from n to arch

docs/architecture/07-dev-principles.md

@@ -0,0 +1,131 @@
+---
+sidebar_position: 7
+---
+
+# Принципы разработки
+
+## 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/)