ООП *

Что такое архитектура ПО и почему она не про красивые диаграммы

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как LEGO, только для взрослых)
✅ Способы взаимодействия компонентов (REST, RPC, события)
✅ Распределение ответственности между модулями
✅ Выбор технологического стека

Простой пример:
Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.

🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.

Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.

Пример компонентов:

• Authentication Service (следит, чтобы чужие не лезли)

• Notification Service (шлёт уведомления)

• Data Storage (хранит данные, очевидно)

Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.

Типы интерфейсов:

• REST API (классика жанра)

• Message Queue (асинхронные сообщения)

• RPC (удалённые вызовы)

• Database API (работа с данными)

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

Примеры связей:

• HTTP-соединения (веб-траффик)

• TCP/UDP сокеты (низкоуровневая связь)

• Message Brokers (Apache Kafka, RabbitMQ)

• Database connections (пул соединений с БД)

Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.

Примеры модулей:

• User Management Module (всё что касается пользователей)

• Payment Processing Module (платежи и транзакции)

• Analytics Module (метрики и отчёты)

Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.

Примеры сервисов:

• Order Service (управление заказами)

• Inventory Service (управление товарами)

• Billing Service (выставление счетов)

Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.

Типы хранилищ:

• Реляционные БД (PostgreSQL, MySQL)

• NoSQL (MongoDB, Redis)

• Файловые системы (S3, локальные диски)

• Кэши (Redis, Memcached)

SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".

Зачем нужны SLA:

• Понимание ожиданий от системы

• Планирование мощностей

• Определение критичности сервисов

• Основа для мониторинга

Практический пример:
Сервис авторизации должен:

• Отвечать за 100ms в 95% случаев

• Быть доступным 99.95% времени

• Выдерживать 1000 RPS

Чеклист для правильного проектирования:
✅ Каждый компонент имеет чёткую ответственность
✅ Интерфейсы документированы
✅ Связи (способы взаимодействия) определены
✅ Деление на сервисы произведено
✅ Способ хранения данных определен
✅ SLA определены и измеряемы
✅ Зависимости между компонентами минимальны

Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.

Из чего состоит MeyerSAN — решение для имитации ошибок в СХД

Проект MeyerSAN — это программно-аппаратный комплекс на основе сервера VEGMAN. Комплекс имитирует неисправность SAS HDD и SSD и позволяет автоматически тестировать реакцию системы хранения данных на ошибки. Решение необходимо для тестирования и валидации работы подсистем, которые находятся в составе СХД и определяют проблемные диски. 

Как это работает: 

1. Мы подключаем сервер к системе хранения данных. 

2. С помощью ПО и драйверов заставляем СХД видеть сервер как диск или несколько дисков.

3. Вносим отклонения в поведение диска. Например, имитируем ситуацию, когда пользователь записал данные в диск, а прочитать их не смог.

Задача MeyerSAN — эмулировать проблемы с дисками: задержки, ошибки, порчу данных и метаданных.

Архитектура MeyerSAN состоит из трех больших блоков: 

1. REST, так называемый MRSNMGMT. Позволяет конфигурировать систему в соответствии с пожеланиями.

2. MRSNLib. Cодержит бизнес-логику приложения: обработку и модификацию команд.

3. Драйверы низкого уровня. Они предоставляют нам механизмы транспорта и позволяют соответствовать всем протоколам.

Средний компонент, MRSNLib, команда разработчиков написала на современном С++ 23. Как именно инженерам удалось интегрировать новейший стандарт, а также паттерны объектно-ориентированного программирования в проект MeyerSAN, рассказывает один из создателей проекта Константин Крюков в новой статье.

Я в прошлом разработчик. Поработал во многих ведущих ИТ-компаниях России. После того, как был разработчиком, работал системным аналитиком, продуктовым менедежром. Лет 12-15 назад начал увлекаться вопросами обучения детей математике. Писал даже года 3 назад на Хабре статью о том, как это мое хобби превратилось в профессию. Теперь это еще и область научных интересов: поступил в аспирантуру на мехмат МГУ на кафедру методики преподавания математики.

В нашем коллективе на мехмате существенная часть внимания сейчас прикована к явленим глубокого структурного изменения взглядов школьника на математику (например, осознание, что от числа можно перейти к переменной, или понимание, что уравнения и неравенства - это одно и то же, с точки зрения логики). У меня на этот счет есть своя теория, которую я частично заимствовал у своего научного руководителя и развил. Теория заключается в том, что задача начальной школы и первой части средней - это осваивать алгоритмы решения различных задач. Т.е. нужно уметь обосновывать каждый шаг алгоритма, но не обязательно уметь находить следующий шаг (достаточно помнить последовательность шагов). К середине средней школы алгоритмов накапливается критическая масса, и школьнику с организацией знаний на основании алгоритмов становится тяжело. Алгоритмы все больше и больше ветвятся, изменяют область своего применения и множатся. И в какой-то момент алгоритмы начинают рваться на шаги, а организация знаний начинает смещаться от алгоритмов к отношениям математических сущностей. Отношения - более оптимальная структура организации знаний. Она отлично работает там, где есть постоянные измнения структуры. Также она оптимальна для организации мышления исследователя. А очень часто дети в началке пропускают обоснование шагов алгоритма и, естественно, имеют проблемы с расчленением алгоритмов на части и формированием математических отношений. И, как следствие, им остается только все продолжать зубрить. Вот пост в моем тг-канале о том, как это прогрессирующее заболевание тянется и меняет представление об обучении.

Пример. Можно воспринимать примеры "2 + 3 = 5", "2 = 5 - 3" и "3 = 5 - 2" по отдельности, тогда знак равно будет знаком дейсвтия. А можно как одно отношение между числами 2, 3 и 5, например, 2 + 3 = 5. А вот тут теперь знак равно имеет смысл тождества.

Развивая теорию, которая могла бы описать такие переходы от алгоритмов к отношениям и которая могла бы быть основной для построения педагогических методик, я вдруг вспомнил, где я это все видел!!!! Функциональное программирование и ООП!!! У каждой из этих двух парадигм есть свои плюсы и минусы. Функциональная хороша для освоения, для быстрого создания чего-то небольшого, для кодирования чего-то большого, когда есть высокая степень определенности, а планируемые изменения не слишком велики. ООП - хорошо, когда планируются структурные изменения. По крайней мере, так было лет 10 назад. А структурные изменения - это именно то, что происходит при изучении математики в средней и старшей школе и далее.

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

Доклад Особенности фреймворка $mol (+ слайды) с PiterJS #72.

О фичах $mol, которых нет в других фреймворках, и о том, зачем они нужны.

Автор - Станислав Яременко. Герой Hyper Dev, Синьор $mol-разработчик.

Писал на Vue, Svelte. Пробовал и другие фреймворки. Как-то раз я загуглил "лучший ui фреймворк", и на первом месте в выдаче оказался $mol. Конечно, я не поверил и начал разбираться...

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Я вот не понимаю, почему Го преподносится как  post-OOP язык, в то время как это явно пре-ООП язык, чисто императивный. Как Бейсик (который не Вижуал) или Паскаль.

И это явно не прогресс, а регресс в подходе к методологии.

Хотя, очевидно, он выигрывает у языков с управляемой средой, да. Управляемая среда (ВМ) требует слишком много ресурсов для старта и разогрева. А в микросервисах это вообще не нужно.

Реализация перераспределения целей (retarget) в играх RTS жанра

Учитывая предыдущую критику, что удобнее читать статьи, а не слушать видео, попробую вначале сделать акцент на тему, вынесенную в заголовок. Дело в том, что в статье концентрация информации больше, но широкий контекст обсуждения вопроса, остается за кадром. Поэтому для узконаправленной подачи информации собираюсь написать статью, а для более широкого понимания вопроса предлагаю ознакомится с представленным видео.

Задача выбора целей для атакующих NPC

В играх RTS жанра обязательно возникает задача, как выбрать для NPC цель. Мы хорошо знаем, когда игроки на их жаргоне говорят "заагрился", что означает, что некий юнит, обратил внимание на юнитов игрока, и будет их преследовать и атаковать. В ряде игр от заагрившегося юнита можно убежать, в других наоборот, он будет вас выслеживать "по запаху, остаткам крови", как это реализовано в JA3. Но как усложнится задача, когда агрессивных NPC в игре сотни, и у игрока аналогично их сотни, или тысячи. Можно ли раз и навсегда заагрится на какого то конкретного юнита? По какому принципу перераспределять цели между разными NPC? Все это не тривиальные задачи, но они имеют одно достаточно простое решение на базе алгоритма искусственного интеллекта, который своими корнями восходит к алгоритму градиентного спуска.

Global variable is not a field!

Глобальная переменная - это не поле для наследования ООП. Эта мысль посетила меня слишком поздно, поймите мою боль.
Я создал глобальную переменную, точнее даже глобальную переменную с локальной областью видимости (static). Эта переменная жила в методе. Я ожидал, что у каждого экземпляра класса будет свой метод (что верно) со своим экземпляром переменной (неверно).

void TClass::method(){
    static QByteArray globalVar; //will the same for all objects
}

Учите ООП, голубцы!