Всем привет!
Этот канал можно будет назвать "записной книжкой", потому что преимущественно здесь будут посты про собственную учебу, разработку чего-либо.
Также буду писать сюда какие-то идеи, мысли, а вы можете их обсуждать и я буду с вами общаться. Возможно даже фрагменты и моменты из жизни.

На данный момент у меня нет достаточных возможностей разрабатывать, так как я немного приболел и помимо этого я нахожусь чуть-чуть🤏 не в том месте, чтобы программировать и творить.

Но кто мне мешает учиться и придумывать что-либо интересное?

- задал я себе такой вопрос.

А ведь правда, что никто мне не запрещает заниматься тем, что мне интересно, что может обеспечить мне жизнь дальнейшую. Запрещаю я себе сам, сидя в телефоне, а может быть иначе... может быть лучше..

Именно под этим предлогом я принимаю решение развиваться дальше, у меня есть для этого самое главное - желание.

С сегодняшнего дня начинаю продолжаю учиться.

P.S.
Возможно, первые посты не будут яркими для этого канала про разработку, но в них можно понять как я рассуждаю и думаю и чего желаю.

#Разработка

В дополнении к прошлому посту хочу добавить, что также будет использоваться технология Git, хорошо известная всем система контроля версий, созданная для хранения кодовых баз, истории, организации и многое другое.

Почему я вообще вспомнил про Git?

Наткнулся на статью в интернете, в которой рассказывается о конвенции коммитов и решил закрепить для себя. Она создана для решения одной известной проблемы: описание коммитов.
Довольно часто новички сильно не задумываются о названии и описании коммитов и пишут в них бессмыслицу. Конвенция же решает эту проблему. Она ввела новый стандарт.

Основные моменты:

- Каждый коммит имеет такую структуру:

<type> [optional scope]: description

[optional body]

[optional footer]

- Основные типы:
1. fix - используется, если коммит является фиксом бага
2. feat - используется, если коммит является внедрением новой feature
3. chore - используется, если изменения коммита не влияют на функциональную часть приложения, также не является фиксом бага, например обновление зависимостей, рефакторинг (без изменения функционала)
4. build - используется, если изменения затрагивают сборку проекта
5. docs - используется, если внедряется/изменяется документация проекта
6. test - используется, если коммит добавил/изменил элементы тестирования

- Если в коммите произошли критические изменения, после типа ставится !, например:

chore!: upgrade node version to 18.1.0

- К типу можно добавлять контекст изменения:

fix(order-page): disable buy button without auth

- description представляет из себя краткое содержание изменений кода:

feat: add table of characteristics for item page

Про body & footer можно почитать в самой статье, что рекомендую.
type & description уже имеют достаточный вес, чтобы удобнее использовать историю коммитов.

#Полезное

На данный момент мой график очень забит и у меня остается едва времени на свободное время, но я все равно нахожу силы на создание поста. Возможно он будет не по теме разработки проекта задуманного, но как минимум поделюсь чем-то интересным, что нашел, прочитал, использовал.

Такие посты не будут объёмные конечно. Также я буду добавлять хэштег к каждому посту, чтобы было проще найти мне и вам что-то нужное.

Случайно нашел удобный загрузчик видео с YouTube - Statcher7.
Можно пользоваться на любой ОС.

Может скачивать видео и даже целые плейлисты! Гибко настраиваются, есть поддержка 4К. Работает быстро и без ограничений.

#Полезное

Вчера не смог выложить пост также по отсутствию времени - исправляемся.

Нашёл бесплатный редактор PDF файлов на macOS, Linux. Работает оффлайн и не требует мощной системы.

Позволяет быстро отредактировать текст, поправить вёрстку, добавить что-либо или даже обрезать страницу.

#Паттерны

Разработкой задуманного, к сожалению, заниматься пока некогда, поэтому временно я буду постить всякие полезности для себя и вас. Скорее всего этот формат постов перетечёт на постоянку параллельно с разработкой.

Наткнулся на известный паттерн Observer. Решил, что нужно закрепить его.

Смысл данного паттерна в том, что у нас должен быть Observer (Подписчик) и Subject (Источник событий). Подписчики подписываются на события источника, а источник при изменении своего состояния уведомляет подписчиком об изменении.
Всем приходит уведомления и подписчики реагируют на него. Все - это весь смысл.

Когда это может быть полезно?

- когда на одно событие реагируют несколько компонентов системы
- когда нужна архитектура, которую легко расширять, благодаря возможности подключения/отключения подписчиком "на лету"
- когда хочется уменьшить зависимость источника от подписчиков

Пример кейса:
Заказ на маркетплейсах. У него есть статусы: создан, оплачен, в пути, ожидает получения, получен.
В данном случае заказ воспринимается как источник событий, а подписчики, к примеру: уведомление, аналитика, начисление бонусов реагируют на на изменение состояния источника, то есть статуса.

#Архитектура

Сегодня я хотел бы поделиться своим взглядом на различные типы архитектур, используемые для создания Frontend-приложений:

- Монолит

Монолитная архитектура предполагает, что все приложение, включая пользовательский интерфейс (UI) и логику, хранится в одной кодовой базе. Она отлично подходит для небольших проектов, не требующих масштабирования, так как обеспечивает удобство отладки и быстрый старт разработки. Однако у этого подхода есть и недостатки: высокая связанность кода и медленная скорость развертывания. Чаще всего монолит используется в случаях, когда требуется быстрый запуск.

- Модульная архитектура

В модульной архитектуре код делится на независимые модули, каждый из которых можно разрабатывать, тестировать и вносить изменения отдельно от остальных. Из плюсов можно выделить возможность параллельной разработки модулей, что снижает сложность кодовой базы. Однако при увеличении количества модулей усложняется масштабирование и обзор кода. Модульная архитектура используется, когда требуется крупный монолит с сохранением модульности без необходимости переписывать код.

- Микрофронтенды

Микрофронтенды представляют собой подход, при котором приложение делится на изолированные друг от друга проекты. Этот метод хорош для команд, где каждая отвечает за свою часть приложения, что упрощает масштабирование. Однако усложняется взаимодействие между этими проектами, а также возникают риски несогласованности UX/UI.

- Feature Sliced Design (FSD)

Это моя любимая архитектура, которую я использую практически всегда. Суть ее заключается в том, что приложение делится на слои, сегменты и слайсы. Слои предотвращают циклические зависимости: слои верхнего уровня могут содержать слои нижнего уровня, но не наоборот. Это создает определенную иерархию, что значительно повышает масштабируемость приложения.

Давайте подробнее рассмотрим слои:

- app: отвечает за конфигурацию приложения, роутинг, хранилище данных и другие аспекты
- pages: хранит страницы
- widgets: объединяет различные фичи, такие как баннеры, формы, посты и меню
- features: содержит бизнес-логику: кнопки авторизации, манипуляции с товарами и т. д.
- entities: хранит данные и логику работы с сущностями приложения
- shared: включает участки кода, которые используются по всему приложению: UI-компоненты, типизацию, хуки и т. д.

Слайсы представляют собой способы взаимодействия: типы, хуки, API, UI и другие. Они содержатся в сегментах.

#Паттерны

К сожалению или счастью, у жизни бывают перемены. Я с ними столкнулся и немного сбился с пути, но сдаваться не буду - пробуем и идем дальше.

Изучил еще один интересный паттерн Command.

Основная идея в том, чтобы использовать единый интерфейс для описания всех типов операций. Тогда для добавления новой операции в системе достаточно реализовать единый интерфейс.

Паттерн полезен, когда нужно:
- сохранять историю действий
- иметь возможность отката и повторения действий
- логирование и протоколирование

Необходимо создать класс Command с методами execute(), cancel(), name(). От него наследуются классы как самостоятельные команды, к примеру: HistoryCommand, UndoCommand, RedoCommand.

Методы:
- execute() - выполняет необходимую логику и сохраняет ее в историю действий
- cancel() - отменяет выполненное действие
- name() - возвращает имя команды

Паттерн определено сказка для терминальных (TUI) приложений