Проектирование и рефакторинг *

Интегрировать две и более системы - это вам не легкая прогулка томным субботним вечером. Через эти системы могут проходить критически важные данные: платежи, логистика, уведомления, идентификация и многое другое. И именно на стыках между системами возникают ошибки, которые очень часто трудно воспроизвести и очень дорого исправлять.

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

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

Не поверхностно, а с разбором боевых кейсов, с примерами и выводами, которые можно вполне себе использовать, как чек-лист. Чтож! Щас выскажусь!)

И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

В статье обсудим антипаттерн Primitive obsession, разберём на примерах способы его устранения в разных языках программирования.

Если вы считаете, что принципы SOLID — это что-то из учебника по ООП и к вашему проекту они не имеют отношения, у меня для вас плохие новости. Так думали и мы, пока один «божественный» класс не положил прод на сутки. А всё потому, что его писали с мыслью «зачем разбивать, всё и так работает».

В этой статье — без академической воды: как SOLID спасает архитектуру, ускоряет команду и помогает не утонуть в легаси. С примерами, с типичными фейлами и с тем, что действительно работает в продакшене.

Я старый фуллстек-разработчик и не знаю слов любви, но около полугода назад при очередной итерации сервера почувствовал себя утомленным путником, который узрел нежную красоту wr-обработчика нативного net/http! Вот раньше всё было ужасно - а теперь красиво, приятно читать и интересно показать! За несколько месяцев я переделал свои сотни обработчиков на новый стиль - и всё еще доволен! Почистил авгиевы конюшни слоев логики - теперь там царит запах фиалок! Также у меня была возможность посмотреть как пилят http профессионалы бэкенда - далеко не как фуллстеки, о чем тоже хочется рассказать!
Для ленивых читать - пора вернуть логику в обработчики! Но я расскажу подробно о той красоте, которая скрывается за этими многими восклицательными знаками, и о том, как её можно испортить. Структура такова:
- сначала чем фуллстек отличается от нативного бэкенда,
- потом пройдемся по API-стилю а-ля РЕСТ,
- прочтем оду нативному http-модулю, расковыряем пару болячек фреймворков,
- почитаем мои слова, почему wr-обработчик хорош сразу из коробки,
- и посмотрим пример того, как превратить обработчик в простой вид "задача-дано-решение-ответ".

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

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени.

Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

Здравствуйте.

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

Первая часть этой истории находится тут. Там можно почерпнуть некоторую информацию о том, что из себя представляет описываемая мной система.  Хотя бы в части устройства базы данных.  А база это наше все!

Привет, Хабр!

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

Статья — технический разбор моей попытки построить сеть каналов‑барахолок в Telegram, которая включала бы в себя все объявления уже существующих и устранила фактор хаоса (спам, коммерция, мусорные сообщения). А так же поверх — бота с подпиской на объявления по ключевыем словам.

Представьте, что ваша компания — это город. Сначала это посёлок с одной улицей, где все знают друг друга и работают сообща. Но когда посёлок превращается в мегаполис, старые правила перестают работать: дороги забиты, свет отключается, а жители бунтуют. То же происходит с IT-платформами: на старте монолит кажется простым решением, но с ростом он душит развитие. Team Topologies предлагает альтернативу — превратить платформу в сеть «умных посёлков», где каждый сервис развивается автономно, но по общим правилам. В статье разберём базу как это работает и посмотрим на примере реальной компаний. 

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

Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства.

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

Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

Здравствуйте.

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

Хочу рассказать об одной самописной системе, которую мы используем уже очень давно. И о ее развитии (в другой статье).

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

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!

Любой программист, вне зависимости от уровня, когда‑то сталкивался с этим. Ты садишься за проект, полный планов и идей, предвкушаешь, как создашь нечто совершенное, но... проходит час, второй, а на экране только десяток папок, пара заглушек и файл README.md. И вот уже начинаешь возвращаться к документации в поисках «правильной» структуры проекта или подсматриваешь, как сделали другие.

Примерно то же самое происходит, когда ты работаешь в команде: собрания перетекают в бесконечное обсуждение архитектуры, абстракций и фреймворков. Идеи летят кометами, все соглашаются, что «всё должно быть как надо», но реальная работа — застопорилась. Потому что команда вместе с тобой подсознательно ждет чего‑то: идеального старта.

Синдром идеального старта — не просто миф, а настоящая преграда для продуктивной разработки. В этой статье мы поговорим о том, почему ждать «идеальности» — значит тормозить, как такой подход мешает развитию, и что с этим можно сделать.

Зачем мы ждём идеального старта?

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

Проблема в том, что идеальное, как правило, недостижимо. Вот почему:

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

Хорошая новость: распутать спагетти-код можно по-разному, и иногда срабатывают не самые очевидные способы. В нашем случае помогла комбинация действий: не просто выделение части кода в отдельные микросервисы, но и параллельная реализация архитектурного подхода DDD Lite (в связке с принципами чистой архитектуры).

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

Привет, хабр!

Сегодня я хотел бы рассказать о том, как можно реализовать оптимистичную блокировку в Hibernate если вы используете DDD, а точнее агрегаты. Если кто-то не в курсе что такое оптимистичная блокировка, то советую сначала почитать это. 

Проблема:

Думаю, многим известно что, в целом, реализация оптимистичной блокировки в Hibernate проще некуда - всё что нужно сделать это добавить поле version с аннотацией @Version в вашу энтити. Bот так: