diff --git a/dev/architecture/Бизнес-логика.md b/dev/architecture/Бизнес-логика.md index b08915e3..ec183f0f 100644 --- a/dev/architecture/Бизнес-логика.md +++ b/dev/architecture/Бизнес-логика.md @@ -2,12 +2,10 @@ aliases: - бизнес-логике - бизнес-логику + - бизнес-логики tags: - maturity/🌱 date: 2024-10-16 -zero-link: -parents: -linked: --- Бизнес-логика — это совокупность правил, процессов и операций, которые определяют, как бизнес-приложение или [[Информационная система|система]] обрабатывает данные и выполняет свои функции в соответствии с требованиями бизнеса. Она описывает последовательность действий, условия и правила, которые управляют поведением системы при выполнении бизнес-задач. diff --git a/dev/architecture/Паттерн проектирования.md b/dev/architecture/Паттерн проектирования.md index de549ac3..ec1d031c 100644 --- a/dev/architecture/Паттерн проектирования.md +++ b/dev/architecture/Паттерн проектирования.md @@ -2,6 +2,7 @@ aliases: - паттерн - шаблон проектирования + - шаблонов проектирования tags: - maturity/🌱 date: 2023-11-05 @@ -45,7 +46,8 @@ linked: - [[MVC]] +- [[Transactional Inbox]] - [[Dependency Injection]] -- [[Порождающий паттерн проектирования]] - [[Transactional Outbox]] +- [[Порождающий паттерн проектирования]] diff --git a/dev/efficiency/Don't Repeat Yourself.md b/dev/efficiency/Don't Repeat Yourself.md new file mode 100644 index 00000000..a2ac2f16 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Keep It Simple, Stupid.md b/dev/efficiency/Keep It Simple, Stupid.md new file mode 100644 index 00000000..9fafc6a4 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Рефакторинг кода.md b/dev/efficiency/Рефакторинг кода.md new file mode 100644 index 00000000..b231940d --- /dev/null +++ b/dev/efficiency/Рефакторинг кода.md @@ -0,0 +1,22 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2024-11-24 +--- +Рефакторинг — это процесс улучшения существующего кода **без изменения его функциональности**. + +Регулярный рефакторинг помогает избавиться от неудачных решений, которые усложняют понимание системы. Устраняя технический долг, команда уменьшает количество контекста, который необходимо удерживать в голове, и делает код понятнее. +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2024-11-24]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Снижение когнитивной нагрузки при разработке.md b/dev/efficiency/Снижение когнитивной нагрузки при разработке.md new file mode 100644 index 00000000..0eba823f --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Соглашение о наименовании.md b/dev/efficiency/Соглашение о наименовании.md new file mode 100644 index 00000000..08bc010c --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Стандартизация подходов в разработке.md b/dev/efficiency/Стандартизация подходов в разработке.md new file mode 100644 index 00000000..b6d1840a --- /dev/null +++ b/dev/efficiency/Стандартизация подходов в разработке.md @@ -0,0 +1,25 @@ +--- +aliases: + - стандартизация подходов +tags: + - maturity/🌱 +date: 2024-11-24 +--- +Чем больше команда придерживается общих стандартов кода и архитектуры, тем проще разработчикам работать с чужим кодом. Наличие стандартов снижает потребность каждый раз принимать решения и позволяет быстро понять, как устроены те или иные части системы. + +Практики, которые позволяют снизить когнетивную нагрузку: +- [[Соглашение о наименовании|Соглашение о наименовании]] +- [[../architecture/Паттерн проектирования|Паттерн проектирования]] +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2024-11-24]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/efficiency/Чистый код.md b/dev/efficiency/Чистый код.md new file mode 100644 index 00000000..9df817fd --- /dev/null +++ b/dev/efficiency/Чистый код.md @@ -0,0 +1,24 @@ +--- +aliases: + - чистого кода +tags: + - maturity/🌱 +date: 2024-11-24 +--- +- [[Соглашение о наименовании]] +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2024-11-24]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Соглашение о наименовании]] + + diff --git a/dev/java/Границы применимости Tuple и Pair в разработке.md b/dev/java/Границы применимости Tuple и Pair в разработке.md index 365e4cdf..7d8e9f71 100644 --- a/dev/java/Границы применимости Tuple и Pair в разработке.md +++ b/dev/java/Границы применимости Tuple и Pair в разработке.md @@ -82,7 +82,7 @@ private Tuple fetchUserData() { - **Удобство и скорость реализации:** Использование `Tuple` может значительно сократить время на реализацию, особенно когда речь идет о простых данных и методах, которые используются в узких контекстах. - **Снижение избыточности кода:** Если данные нужны только внутри класса и их использование ограничено несколькими методами, создание отдельного класса может казаться избыточным. `Tuple` позволяет избежать ненужной сложности и дополнительных файлов. -Тем не менее, стоит помнить о проблемах Tuple. Если логика метода со временем усложниться, читаемость кода может понизится. +Тем не менее, стоит помнить о проблемах Tuple. Если логика метода со временем усложниться, [[../Читаемый код|читаемость кода]] может понизится. **Когда стоит задуматься о создании отдельного класса:** - Если структура данных становится сложной или используется в нескольких местах внутри класса. @@ -118,7 +118,7 @@ Uni orderUni = getOrder() Когда использование различных Tuple оправдано: - **Переходные стадии в пайпах:** Внутри реактивных потоков, `Tuple2`, `Tuple3` и другие позволяют временно объединять нужное количество значений для обработки, сохраняя компактность и удобство. -- **Локальные переменные для улучшения читаемости:** Извлечение значений `Tuple` в локальные переменные с осмысленными именами значительно улучшает читаемость кода и упрощает понимание логики. +- **Локальные переменные для улучшения читаемости:** Извлечение значений `Tuple` в локальные переменные с осмысленными именами значительно улучшает [[../Читаемый код|читаемость кода]] и упрощает понимание логики. Ограничения: - **Сложность при увеличении количества элементов:** Чем больше значений объединяется в `Tuple` (например, `Tuple4`, `Tuple5` и далее), тем сложнее становится поддерживать и понимать код. В таких случаях лучше рассмотреть создание именованных классов. diff --git a/dev/java/Статическая фабрика в Java.md b/dev/java/Статическая фабрика в Java.md index 2c02028e..1a97080a 100644 --- a/dev/java/Статическая фабрика в Java.md +++ b/dev/java/Статическая фабрика в Java.md @@ -7,7 +7,7 @@ zero-link: parents: linked: --- -[[../other/Статическая фабрика|Статическая фабрика]] в Java — это метод, который возвращает экземпляры класса, но вместо создания объектов через конструктор, используется статический метод. Такой подход дает разработчику гибкость в процессе создания объектов, возможность кэширования и возвращения уже созданных экземпляров, а также улучшает читаемость кода за счет осмысленных имен методов, таких как `of()` или `valueOf()`. +[[../other/Статическая фабрика|Статическая фабрика]] в Java — это метод, который возвращает экземпляры класса, но вместо создания объектов через конструктор, используется статический метод. Такой подход дает разработчику гибкость в процессе создания объектов, возможность кэширования и возвращения уже созданных экземпляров, а также улучшает [[../Читаемый код|читаемость кода]] за счет осмысленных имен методов, таких как `of()` или `valueOf()`. Статическая фабрика часто используется для реализации паттернов, таких как Singleton, а также для создания объектов, требующих дополнительной логики при инициализации. diff --git a/dev/linux/Распространеные порты TCP и UDP.md b/dev/linux/Распространеные порты TCP и UDP.md new file mode 100644 index 00000000..b8d541b9 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/Комментарии в коде.md b/dev/Комментарии в коде.md new file mode 100644 index 00000000..f6dbcf0b --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/Читаемый код.md b/dev/Читаемый код.md index b4440406..ae7473b1 100644 --- a/dev/Читаемый код.md +++ b/dev/Читаемый код.md @@ -3,21 +3,23 @@ aliases: - читаемость кода - читаемости кода - читаем код + - код пишется для людей, а не для машин + - понимания кода tags: - maturity/🌱 - content/opinion date: 2024-10-20 --- -Код — это не только набор инструкций для машины, но и ==средство общения между разработчиками.== Большую часть времени программисты проводят, читая чужой код, поэтому ==каждый фрагмент кода должен быть понятен не только автору, но и другим членам команды==. Удобство чтения и понимания кода коллегами — один из ключевых факторов успешной [[../productivity/Эффективная команда разработки|командной работы]]. +Код — это не просто набор инструкций для машины, но и средство коммуникации между разработчиками. ==Программисты проводят большую часть времени, читая чужой код.== Поэтому каждый фрагмент кода должен быть понятен не только автору, но и другим членам команды. Удобочитаемость и понятность кода для коллег — ключевые факторы успешной [[../productivity/Эффективная команда разработки|командной работы]]. -==Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям==. Если ваш код понятен только вам и не может быть поддержан другими, это сигнал того, что вы посредственный разработчик. +Хорошо написанный код снижает [[efficiency/Снижение когнитивной нагрузки при разработке|когнитивную нагрузку]] на разработчиков. Любой может написать код, который поймёт компьютер. ==Хорошие программисты пишут код, который понятен людям.== Если ваш код понятен только вам и не может быть поддержан другими, это явный сигнал того, что вы не справляетесь с задачей качественного написания кода. **Рекомендации**: - **Пишите просто и ясно**. Используйте понятные и распространённые конструкции языка, которые легко читаются и понимаются коллегами. - **Не усложняйте**. Не стремитесь использовать сложные или малоизвестные возможности языка, если они не приносят очевидной пользы. ==Простота всегда предпочтительнее.== -- **Комментируйте важные моменты**. Там, где логика может быть неочевидной, добавьте комментарии, которые объясняют цель или обоснование ваших решений. -- **Следуйте соглашениям по стилю**. Соблюдайте единые стандарты кодирования, принятые в команде, будь то соглашения о стиле, именовании или форматировании. -- **Используйте осмысленные имена**. Переменные, функции и классы должны иметь названия, которые чётко отражают их назначение. Избегайте сокращений, если они могут быть непонятны другим. +- **Комментируйте важные моменты**. Там, где логика может быть неочевидной, добавьте [[Комментарии в коде|комментарии]], которые объясняют цель или обоснование ваших решений. +- [[efficiency/Стандартизация подходов в разработке|Стандартизация подходов в разработке]]. Соблюдайте единые стандарты кодирования, принятые в команде, будь то соглашения о стиле, именовании или форматировании. +- Используйте [[efficiency/Соглашение о наименовании|осмысленные имена]]. Переменные, функции и классы должны иметь названия, которые чётко отражают их назначение. Избегайте сокращений, если они могут быть непонятны другим. - **Проводите регулярные ревью кода**. Обратная связь от коллег помогает выявить возможные сложности в понимании кода и улучшить его качество. *** diff --git a/meta/files/images/telegram-cloud-photo-size-2-5323372910263526110-y.jpg b/meta/files/images/telegram-cloud-photo-size-2-5323372910263526110-y.jpg new file mode 100644 index 00000000..7758a3a6 Binary files /dev/null and b/meta/files/images/telegram-cloud-photo-size-2-5323372910263526110-y.jpg differ diff --git a/meta/files/images/webp/telegram-cloud-photo-size-2-5323372910263526110-y.webp.md5 b/meta/files/images/webp/telegram-cloud-photo-size-2-5323372910263526110-y.webp.md5 new file mode 100644 index 00000000..0d885398 --- /dev/null +++ b/meta/files/images/webp/telegram-cloud-photo-size-2-5323372910263526110-y.webp.md5 @@ -0,0 +1 @@ +5c5e83a0038b26028fe779a845824761 diff --git a/meta/zero/00 Эффективная разработка.md b/meta/zero/00 Эффективная разработка.md new file mode 100644 index 00000000..b449f4fd --- /dev/null +++ b/meta/zero/00 Эффективная разработка.md @@ -0,0 +1,16 @@ +--- +aliases: + - Эффективная разработка +tags: + - type/zero-link +date: 2024-11-24 +parents: + - "[[00 Разработка]]" +--- + + +- [[Стандартизация подходов в разработке]] +- [[Снижение когнитивной нагрузки при разработке]] +- [[Соглашение о наименовании]] +- [[Чистый код]] +