Обновление

dev/architecture/Бизнес-логика.md

@@ -2,12 +2,10 @@
 aliases:
   - бизнес-логике
   - бизнес-логику
+  - бизнес-логики
 tags:
   - maturity/🌱
 date: 2024-10-16
-zero-link: 
-parents: 
-linked:
 ---
 Бизнес-логика — это совокупность правил, процессов и операций, которые определяют, как бизнес-приложение или [[Информационная система|система]] обрабатывает данные и выполняет свои функции в соответствии с требованиями бизнеса. Она описывает последовательность действий, условия и правила, которые управляют поведением системы при выполнении бизнес-задач.
 

dev/architecture/Паттерн проектирования.md

@@ -2,6 +2,7 @@
 aliases:
   - паттерн
   - шаблон проектирования
+  - шаблонов проектирования
 tags:
   - maturity/🌱
 date: 2023-11-05
@@ -45,7 +46,8 @@ linked:
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 - [[MVC]]
+- [[Transactional Inbox]]
 - [[Dependency Injection]]
-- [[Порождающий паттерн проектирования]]
 - [[Transactional Outbox]]
+- [[Порождающий паттерн проектирования]]
 <!-- SerializedQuery END -->

dev/efficiency/Don't Repeat Yourself.md

@@ -0,0 +1,36 @@
+---
+aliases:
+  - DRY
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Принцип DRY направлен на устранение избыточности в коде и обеспечение его поддерживаемости.
+
+Суть принципа DRY заключается в том, чтобы избегать дублирования информации, логики или кода. Каждая часть функциональности системы должна быть реализована в одном месте, чтобы избежать дублирования. Это помогает избежать ситуаций, когда один и тот же код приходится изменять в нескольких местах, что увеличивает риск ошибок и усложняет поддержку.
+
+Также принцип DRY часто применяется при проектировании базы данных. Когда данные нормализованы, однотипная информация хранится в одном месте, что снижает избыточность и упрощает её изменение.
+
+**Преимущества принципа DRY**
+- **Упрощение поддержки**. Когда логика сосредоточена в одном месте, любые изменения в ней вносятся единожды, что делает код проще в сопровождении. Например, если логика вычисления налогов вынесена в отдельный модуль, изменения в налоговых правилах потребуют правки только в этом модуле. Это снижает вероятность ошибок и помогает быстрее вносить правки.
+- **Улучшение читаемости**. Код, в котором нет дублирования, проще читать и понимать. Каждый модуль или компонент [[../architecture/Single Responsibility Principle|выполняет свою конкретную задачу]], что улучшает структуру и восприятие проекта.
+- **Снижение рисков ошибок**. Дублированный код часто ведет к несогласованности и ошибкам при изменениях. DRY помогает поддерживать целостность системы и снижает риск возникновения ошибок из-за некорректных правок в одном из дублирующихся мест.
+- **Ускорение разработки**. Избавление от дублирования позволяет быстрее добавлять новые функции или изменять существующие, поскольку разработчики могут сосредоточиться на одной реализации, а не искать все места, где повторяется похожий код.
+
+**Примеры нарушения DRY**
+- Дублирование одного и того же кода в разных модулях вместо вынесения его в общий компонент.
+- Копирование и вставка бизнес-логики вместо использования общих методов.
+- Повторное хранение одинаковой информации в разных таблицах базы данных.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Keep It Simple, Stupid.md

@@ -0,0 +1,41 @@
+---
+aliases:
+  - KISS
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Принцип KISS — это один из ключевых подходов в программировании и инженерии, подчеркивающий важность простоты в проектах и системах. Аббревиатура KISS расшифровывается как "Keep It Simple, Stupid", что можно перевести как "Делай проще, глупец". Несмотря на довольно грубую формулировку, основная цель этого принципа — подчеркивать важность простоты и избегать излишней сложности при разработке.
+
+Суть KISS заключается в том, что ==решения должны быть настолько простыми, насколько это возможно.== Это предполагает минимальное количество зависимостей, отсутствие лишних функций и легкость [[../Читаемый код|понимания кода]]. Вся система или её части должны быть доступны для понимания как опытным разработчикам, так и тем, кто только подключился к проекту.
+
+Следование принципу KISS предполагает избегание сложных архитектур и предпочтение более простых решений, когда это возможно. Например, если функциональность можно реализовать с помощью простого цикла и пары условий, лучше не добавлять сложные шаблоны проектирования без явной необходимости.
+
+Часто разработчики сталкиваются с искушением использовать модные технологии или сложные архитектурные решения, чтобы продемонстрировать свои навыки. Однако KISS напоминает о том, что код должен в первую очередь решать задачу, а не демонстрировать мастерство программиста.
+
+В конечном итоге, KISS помогает создавать устойчивые и поддерживаемые проекты, что особенно важно в условиях ограниченного времени и ресурсов.
+
+**Преимущества принципа KISS**
+1. **Легкость поддержки**. Простые решения требуют меньше усилий на поддержку. Например, использование стандартных библиотек вместо написания собственных решений позволяет сократить количество кода и облегчить его поддержку. В случае возникновения ошибок, их гораздо проще найти и исправить.
+2. **Масштабируемость**. Чем проще система, тем легче её масштабировать, добавляя новые модули или функции без риска повредить основную логику.
+3. Улучшение [[../Читаемый код|читаемости кода]]. Простой код проще читать, а значит, его легче понимать новым членам команды. Это снижает порог вхождения для новых разработчиков.
+4. **Снижение рисков ошибок**. Чем меньше сложностей, тем ниже вероятность возникновения ошибок, связанных с избыточной логикой или излишними зависимостями.
+5. Простота также способствует более быстрой адаптации новых членов команды, так как упрощает понимание системы и сокращает время на освоение кода.
+
+**Примеры нарушения KISS**
+- Использование излишне сложных паттернов там, где можно обойтись простым решением.
+- Добавление ненужных абстракций, которые затрудняют понимание структуры кода.
+- Введение избыточных зависимостей, которые усложняют настройку и поддержку системы.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Рефакторинг кода.md

@@ -0,0 +1,22 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Рефакторинг — это процесс улучшения существующего кода **без изменения его функциональности**.
+
+Регулярный рефакторинг помогает избавиться от неудачных решений, которые усложняют понимание системы. Устраняя технический долг, команда уменьшает количество контекста, который необходимо удерживать в голове, и делает код понятнее.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Снижение когнитивной нагрузки при разработке.md

@@ -0,0 +1,30 @@
+---
+aliases:
+  - когнитивную нагрузку
+  - снижать когнетивную нагрузку
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Когнитивная нагрузка — это объем ментальных усилий, который разработчики прикладывают для выполнения своих задач. Слишком высокая когнитивная нагрузка может приводить к ошибкам, снижению продуктивности и [[../../../../knowledge/health/болезни/Эмоциональное выгорание|выгоранию]]. Поэтому важно принимать меры по ее снижению. Рассмотрим, какие практики помогают уменьшить нагрузку и сделать процесс разработки более комфортным и эффективным.
+
+- [[Стандартизация подходов в разработке]]
+- [[Keep It Simple, Stupid]]
+- [[Рефакторинг кода]]
+- Документация и [[../Комментарии в коде|комментирование кода]]
+- [[Don't Repeat Yourself]]
+- **Разделение задач на мелкие части**. Разделение больших задач на мелкие и четко определенные части позволяет легче управлять процессом разработки и снижает когнитивную нагрузку. Выполнение небольшой задачи проще и требует меньше усилий, чем работа с большим блоком, который трудно полностью удержать в голове.
+- **Инструменты автоматизации** Инструменты, которые автоматизируют повторяющиеся действия, значительно снижают когнитивную нагрузку. Например, использование систем CI/CD для автоматической сборки и тестирования, статического анализа кода и инструментов мониторинга позволяет не отвлекаться на рутину и сосредоточиться на решении более сложных задач.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Соглашение о наименовании.md

@@ -0,0 +1,37 @@
+---
+aliases:
+  - осмысленные имена
+  - соглашений о наименовании
+  - правила именования
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Одним из важнейших аспектов [[Чистый код|чистого кода]] является соблюдение правил именования. Понятные и согласованные имена позволяют улучшить читаемость и поддержку вашего кода. Рассмотрим несколько ключевых принципов:
+## Соблюдайте соглашения стиля
+Используйте общепринятые соглашения стиля для вашего языка программирования. Например, `camelCase` для переменных и методов, а `PascalCase` — для классов. Соглашения стиля могут варьироваться в зависимости от проекта или команды, и важно придерживаться общепринятых правил в данной среде. ==Важно соблюдать единообразие в стиле, чтобы упрощать навигацию по коду и снижать [[Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]].==
+## Выбирайте описательные имена
+Чем точнее имя, тем легче понять назначение функции или переменной. Например, если функция конвертирует валюты, дайте ей имя, которое явно указывает на её назначение, а не абстрактное название вроде `convert`.
+
+Описательные имена облегчают понимание и поддержку кода, но важно сохранять баланс между описательностью и длиной имени, чтобы избежать чрезмерно длинных названий. Описательные имена облегчают понимание и поддержку кода.
+## Избегайте двусмысленных названий
+Избегайте абстрактных названий, которые могут вызвать неясности. Например, если работаете с валютами, используйте явные обозначения, такие как `usdToEur`, чтобы избежать путаницы с другими типами долларов (США, Австралии, Канады и т.д.). Также рекомендуется использовать общеизвестные аббревиатуры для валют, если это делает код короче и при этом понятным.
+## Используйте произносимые имена
+Не сокращайте названия переменных до непонятных сокращений, вроде `cstmrLst`, когда можно использовать `customerList`. Это снижает [[Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]] и делает код более доступным для чтения. Использование полных слов также помогает при устном обсуждении кода в команде.
+## Избегайте магических чисел
+Если в вашем коде присутствуют числовые значения, например коэффициент `0.9` для какой-либо операции, не вставляйте его напрямую. Определите его как константу, например, `CONVERSION_RATE = 0.9`, и используйте это имя в расчетах. Такой подход делает код более понятным и облегчает его поддержку, а также помогает избежать ошибок при изменении значений в будущем. Использование констант также облегчает автоматическое документирование и улучшает понимание кода новыми разработчиками.
+## Чтение кода должно быть легким
+Читатели вашего кода должны сосредотачиваться на логике, а не пытаться расшифровать странные имена переменных и функций. Чем понятнее ваш код, тем проще его поддерживать и развивать. Также рекомендуется использовать [[Комментарии в коде|комментарии в коде]], если имена переменных или логика могут быть неочевидными.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: [[Чистый код]]
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Стандартизация подходов в разработке.md

@@ -0,0 +1,25 @@
+---
+aliases:
+  - стандартизация подходов
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+Чем больше команда придерживается общих стандартов кода и архитектуры, тем проще разработчикам работать с чужим кодом. Наличие стандартов снижает потребность каждый раз принимать решения и позволяет быстро понять, как устроены те или иные части системы. 
+
+Практики, которые позволяют снизить когнетивную нагрузку:
+- [[Соглашение о наименовании|Соглашение о наименовании]]
+- [[../architecture/Паттерн проектирования|Паттерн проектирования]]
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/efficiency/Чистый код.md

@@ -0,0 +1,24 @@
+---
+aliases:
+  - чистого кода
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+- [[Соглашение о наименовании]]
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+- [[Соглашение о наименовании]]
+<!-- SerializedQuery END -->
+

dev/java/Границы применимости Tuple и Pair в разработке.md

@@ -82,7 +82,7 @@ private Tuple<String, Integer> fetchUserData() {
 - **Удобство и скорость реализации:** Использование `Tuple` может значительно сократить время на реализацию, особенно когда речь идет о простых данных и методах, которые используются в узких контекстах.
 - **Снижение избыточности кода:** Если данные нужны только внутри класса и их использование ограничено несколькими методами, создание отдельного класса может казаться избыточным. `Tuple` позволяет избежать ненужной сложности и дополнительных файлов.
 
-Тем не менее, стоит помнить о проблемах Tuple. Если логика метода со временем усложниться, читаемость кода может понизится.
+Тем не менее, стоит помнить о проблемах Tuple. Если логика метода со временем усложниться, [[../Читаемый код|читаемость кода]] может понизится.
 
 **Когда стоит задуматься о создании отдельного класса:**
 - Если структура данных становится сложной или используется в нескольких местах внутри класса.
@@ -118,7 +118,7 @@ Uni<Order> orderUni = getOrder()
 
 Когда использование различных Tuple оправдано:
 - **Переходные стадии в пайпах:** Внутри реактивных потоков, `Tuple2`, `Tuple3` и другие позволяют временно объединять нужное количество значений для обработки, сохраняя компактность и удобство.
-- **Локальные переменные для улучшения читаемости:** Извлечение значений `Tuple` в локальные переменные с осмысленными именами значительно улучшает читаемость кода и упрощает понимание логики.
+- **Локальные переменные для улучшения читаемости:** Извлечение значений `Tuple` в локальные переменные с осмысленными именами значительно улучшает [[../Читаемый код|читаемость кода]] и упрощает понимание логики.
 
 Ограничения:
 - **Сложность при увеличении количества элементов:** Чем больше значений объединяется в `Tuple` (например, `Tuple4`, `Tuple5` и далее), тем сложнее становится поддерживать и понимать код. В таких случаях лучше рассмотреть создание именованных классов.

dev/java/Статическая фабрика в Java.md

@@ -7,7 +7,7 @@ zero-link:
 parents: 
 linked:
 ---
-[[../other/Статическая фабрика|Статическая фабрика]] в Java — это метод, который возвращает экземпляры класса, но вместо создания объектов через конструктор, используется статический метод. Такой подход дает разработчику гибкость в процессе создания объектов, возможность кэширования и возвращения уже созданных экземпляров, а также улучшает читаемость кода за счет осмысленных имен методов, таких как `of()` или `valueOf()`.
+[[../other/Статическая фабрика|Статическая фабрика]] в Java — это метод, который возвращает экземпляры класса, но вместо создания объектов через конструктор, используется статический метод. Такой подход дает разработчику гибкость в процессе создания объектов, возможность кэширования и возвращения уже созданных экземпляров, а также улучшает [[../Читаемый код|читаемость кода]] за счет осмысленных имен методов, таких как `of()` или `valueOf()`.
 
 Статическая фабрика часто используется для реализации паттернов, таких как Singleton, а также для создания объектов, требующих дополнительной логики при инициализации.
 

dev/linux/Распространеные порты TCP и UDP.md

@@ -0,0 +1,20 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+![[../../meta/files/images/telegram-cloud-photo-size-2-5323372910263526110-y.jpg|1000]]
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Linux|00 Linux]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/Комментарии в коде.md

@@ -0,0 +1,64 @@
+---
+aliases:
+  - комментирование кода
+  - комментарии
+tags:
+  - maturity/🌱
+date: 2024-11-24
+---
+
+[[Читаемый код|Код пишется для людей, а не для машин]]. Машины выполняют код без пояснений, но разработчикам важен контекст и намерение автора. Комментарии в коде помогают разработчикам быстрее понять написанный код.
+
+==Комментарии не заменяют полноценную документацию, но они являются дополнительным способом объяснить неочевидные моменты кода.== Вот несколько ситуаций, когда комментарии могут быть особенно полезны:
+
+**Сложные или неочевидные участки кода.** Например, регулярные выражения могут быть весьма сложными для понимания. Комментарий может объяснить, что делает регулярное выражение, делая код более доступным:
+
+   ```python
+   # Найти все слова, начинающиеся с буквы 'f'
+   f_words = re.findall('\bf\w+\b', text)
+   
+   # Найти все слова, начинающиеся с буквы 'l'
+   l_words = re.findall('\bl\w+\b', text)
+   ```
+
+**Выделение блоков кода**. Комментарии могут использоваться для логического разделения кода на блоки, особенно если один блок выполняет конкретную задачу. Например, при настройке стейт-машины комментарии могут помочь выделить разные состояния:
+
+   ```java
+// SCORING
+.withExternal().source(ApplicationState.SCORING).target(ApplicationState.CANCEL).event(ApplicationEvent.SCORING_FAILED)
+.and()
+.withExternal().source(ApplicationState.SCORING).target(ApplicationState.OFFER).event(ApplicationEvent.SCORING_PASSED)
+.and()
+
+// OFFER
+.withExternal().source(ApplicationState.OFFER).target(ApplicationState.CANCEL).event(ApplicationEvent.OFFER_DENIED)
+   ```
+
+Такие комментарии помогают быстрее ориентироваться в коде, особенно если он состоит из множества однотипных действий.
+## Вредные комментарии в коде
+Важно понимать, что не все комментарии полезны. Иногда они могут ухудшить [[Читаемый код|читаемость кода]] или ввести в заблуждение:
+
+**Избыточные комментарии**: Если комментарий просто повторяет то, что уже очевидно из кода, он загромождает его и мешает сосредоточиться на важном. Вместо комментария лучше использовать осмысленное название переменной, чтобы само имя передавало значение. Например:
+
+  ```python
+  age = 14  # возраст
+  ```
+
+Здесь комментарий не добавляет ничего полезного, так как и так понятно, что переменная `age` обозначает возраст.
+
+**Ненужные встроенные комментарии**: Встроенные комментарии, особенно когда они объясняют очевидные операции, могут мешать чтению. Лучше избегать таких комментариев и вместо этого делать код максимально самодокументируемым, используя осмысленные названия переменных и функций.
+
+**Старый закомментированный код**: Закомментированный старый код часто остается в проекте и загромождает его. Если код больше не нужен, лучше удалить его, ведь все изменения сохраняются в системе контроля версий (например, Git).
+***
+## Мета информация
+**Область**:: [[../meta/zero/00 Разработка|00 Разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-24]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/Читаемый код.md

@@ -3,21 +3,23 @@ aliases:
   - читаемость кода
   - читаемости кода
   - читаем код
+  - код пишется для людей, а не для машин
+  - понимания кода
 tags:
   - maturity/🌱
   - content/opinion
 date: 2024-10-20
 ---
-Код — это не только набор инструкций для машины, но и ==средство общения между разработчиками.== Большую часть времени программисты проводят, читая чужой код, поэтому ==каждый фрагмент кода должен быть понятен не только автору, но и другим членам команды==. Удобство чтения и понимания кода коллегами — один из ключевых факторов успешной [[../productivity/Эффективная команда разработки|командной работы]].
+Код — это не просто набор инструкций для машины, но и средство коммуникации между разработчиками. ==Программисты проводят большую часть времени, читая чужой код.== Поэтому каждый фрагмент кода должен быть понятен не только автору, но и другим членам команды. Удобочитаемость и понятность кода для коллег — ключевые факторы успешной [[../productivity/Эффективная команда разработки|командной работы]].
 
-==Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям==. Если ваш код понятен только вам и не может быть поддержан другими, это сигнал того, что вы посредственный разработчик.
+Хорошо написанный код снижает [[efficiency/Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]] на разработчиков. Любой может написать код, который поймёт компьютер. ==Хорошие программисты пишут код, который понятен людям.== Если ваш код понятен только вам и не может быть поддержан другими, это явный сигнал того, что вы не справляетесь с задачей качественного написания кода.
 
 **Рекомендации**:
 - **Пишите просто и ясно**. Используйте понятные и распространённые конструкции языка, которые легко читаются и понимаются коллегами.
 - **Не усложняйте**. Не стремитесь использовать сложные или малоизвестные возможности языка, если они не приносят очевидной пользы. ==Простота всегда предпочтительнее.==
-- **Комментируйте важные моменты**. Там, где логика может быть неочевидной, добавьте комментарии, которые объясняют цель или обоснование ваших решений.
-- **Следуйте соглашениям по стилю**. Соблюдайте единые стандарты кодирования, принятые в команде, будь то соглашения о стиле, именовании или форматировании.
-- **Используйте осмысленные имена**. Переменные, функции и классы должны иметь названия, которые чётко отражают их назначение. Избегайте сокращений, если они могут быть непонятны другим.
+- **Комментируйте важные моменты**. Там, где логика может быть неочевидной, добавьте [[Комментарии в коде|комментарии]], которые объясняют цель или обоснование ваших решений.
+- [[efficiency/Стандартизация подходов в разработке|Стандартизация подходов в разработке]]. Соблюдайте единые стандарты кодирования, принятые в команде, будь то соглашения о стиле, именовании или форматировании.
+- Используйте [[efficiency/Соглашение о наименовании|осмысленные имена]]. Переменные, функции и классы должны иметь названия, которые чётко отражают их назначение. Избегайте сокращений, если они могут быть непонятны другим.
 - **Проводите регулярные ревью кода**. Обратная связь от коллег помогает выявить возможные сложности в понимании кода и улучшить его качество.
 
 ***

meta/files/images/webp/telegram-cloud-photo-size-2-5323372910263526110-y.webp.md5

@@ -0,0 +1 @@
+5c5e83a0038b26028fe779a845824761

meta/zero/00 Эффективная разработка.md

@@ -0,0 +1,16 @@
+---
+aliases:
+  - Эффективная разработка
+tags:
+  - type/zero-link
+date: 2024-11-24
+parents:
+  - "[[00 Разработка]]"
+---
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Область, this.file.link) or contains(zero-link, this.file.link) -->
+<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Область, this.file.link) or contains(zero-link, this.file.link) -->
+- [[Стандартизация подходов в разработке]]
+- [[Снижение когнитивной нагрузки при разработке]]
+- [[Соглашение о наименовании]]
+- [[Чистый код]]
+<!-- SerializedQuery END -->