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

Пассажир меняет билет прямо в дороге — а маршрут собран из трёх GDS и ж/д. Что происходит с данными

Сотруднику нужно долететь до одного города, доехать поездом до другого, и обратно тем же путём — одна командировка, билеты из разных систем бронирования. А потом он уже в дороге пишет в телеграм: "планы изменились, летим не туда, перебронируй".

Три системы под самолёты — Amadeus, Sabre, Travelport: исторически несовместимые XML-диалекты одного и того же понятия перелёта, выросшие из мейнфреймов 60-80-х, каждый со своими причудами и полями, которых нет у соседа. Плюс отдельная, никак не связанная с ними система бронирования под железную дорогу — свой формат, своя логика мест и классов, ничего общего по структуре с авиационными GDS. Запросить всё это параллельно, свести разноформатные ответы в одно и собрать из них валидный маршрут по стыковкам — уже само по себе задача не для россыпи if и ручных мапперов.

А потом человек уже в дороге меняет одно плечо маршрута. Один перелёт уже случился — трогать нельзя. Один — впереди, подлежит замене. И весь маршрут не по шаблону "туда-обратно", а любой длины и состава: сегодня две пересадки, завтра — четыре, послезавтра прямо в дороге вставили лишний вылет.

Тут ломаются две разные вещи, и почти всегда решают только одну.

Первая — как описать саму логику поверх этого зоопарка источников. И сбор из четырёх систем разом, и ветка "можно менять / нельзя менять" превращаются либо в DSL на языке общепринятых интеграционных паттернов (Scatter-Gather, Content-Based Router — тот же словарь, что у Apache Camel), который прочитает и поймёт человек, ни разу его не писавший, — либо в код, который через полгода не восстановит и автор.

Вторая — куда положить результат. Маршрут — не два поля outbound/return, а последовательность разнотипных плеч (самолёт ≠ поезд), где число элементов и состав не известны заранее и меняются посреди собственной жизни объекта. Стандартный ответ — либо гора nullable-колонок под все виды транспорта разом, либо миграция на каждый новый вид.

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

Скоро.

ссылки: хабр redb.ru

Элегантность кода благодаря C++23

Продолжим разбирать приёмы рефакторинга и посмотрим, как std::ranges::views::enumerate помогает сделать код более элегантным.

В статье "C++: Пиши, сокращай, оптимизируй" я рассматривал рефакторинг и оптимизацию кода за счёт объединения циклов. В итоге я остановился на следующем варианте кода:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes)
{
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes))
  {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  //....
}

Его недостаток в том, что всё равно необходимо использовать переменную q для работы с контейнером strides. Как можно написать ещё лаконичнее, я не сообразил, но такой способ есть!

После публикации мне подсказали про enumerate. Эта штука появилась в C++23, и я как-то её пропустил. Сложно уследить за всеми нововведениями C++.

С помощью enumerate можно сразу перебирать и элементы, и их индексы:

constexpr static auto v = {'A', 'B', 'C', 'D'};
for (auto const [index, letter] : std::views::enumerate(v))
    std::cout << '(' << index << ':' << letter << ") ";

Будет напечатано: (0:A) (1:B) (2:C) (3:D).

Но нам нужен обратный порядок, и такой вариант не подходит:

for (auto const [i, sz] :
  std::views::enumerate(
    std::ranges::views::reverse(sizes)))

Этот цикл будет перебирать элементы с конца, а индексы — по возрастанию от 0. Можно сделать, чтобы значения i также шли в обратном порядке? Можно. Это делается с помощью std::views::enumerate(sizes) | std::views::reverse.

В итоге можно сократить код ещё на одну строчку:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes)
{
  std::vector<int64_t> strides(sizes.size());
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto const [i, sz] : std::views::enumerate(sizes) | std::views::reverse)
  {
    strides[i] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  //....
}

Нельзя назвать это большим достижением, но зато на практике применили одну из новых возможностей C++23.

Что со скоростью кода? Замер показал, что в рамках погрешности его скорость не изменилось. Т.е. этот вариант работает так же, как вариант №2 — "Мой вариант одним циклом" (см. замер скорости работы в статье). Это не удивительно, так как по сути код идентичен предыдущему.

Спасибо за внимание и подписывайтесь на наш дайджест, чтобы не пропустить интересное. Например, у нас грядёт выпуск PVS-Studio 8.0 с поддержкой новых языков.

Почему я перестал удалять пользователей сразу

Раньше логика удаления у меня была максимально простой:

DELETE FROM users
WHERE subscription_end < NOW();

Пока проект небольшой, кажется, что этого достаточно. Но потом начинаешь учитывать, что происходит вокруг. 
Обработчик платежей может еще не закончить работу. Webhook мог прилететь повторно. Воркер может обработать событие с небольшой задержкой. В результате возникает гонка между обновлением подписки и задачей удаления.

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

Теперь сначала пользователь получает статус pending_deletion, а отдельная задача спустя заданный интервал еще раз проверяет его состояние. Если за это время подписка продлилась, платеж обработался или статус изменился, удаление просто отменяется. По сути это обычная перепроверка перед необратимой операцией. С тех пор я стараюсь применять этот принцип не только к удалению пользователей. Если действие нельзя легко отменить, одной проверки условия перед выполнением уже недостаточно.

Поделитесь, кто как делает? используете отложенное удаление, soft delete или сразу выполняете операцию, если условие выполнено?

System Design на собеседовании: как не утонуть в требованиях, нагрузках и архитектуре

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

В новом выпуске AvitoCode Саша Кучук, тимлид в Авито, разбирает весь путь от постановки задачи до финальной защиты решения:

• как собирать требования и не упустить нефункциональные;

• как быстро прикинуть нагрузку и не закопаться в расчётах;

• как выстроить домены и API, перейти от high-level к low-level design;

• как выбирать технологии под конкретные ограничения;

• как вести себя на защите решения и на что смотрят интервьюеры при оценке.

Кстати, если тема зашла — Саша также ведёт свой телеграм-канал, где регулярно разбирает похожие кейсы и делится наблюдениями из практики собеседований.

Смотреть:
📺  YouTube
🔵 ВК 
📌 RuTube

Программирование с явно выделенным состоянием

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

Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию.

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

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

Представлен открытый архитектурный инструмент Pascal Editor (3D building editor built with React Three Fiber and WebGPU), который работает прямо в браузере. Рисуем стены, перекрытия и крыши, ставим двери, окна и мебель, собираем несколько этажей и переключаемся между 2D‑планом и 3D. Готовый дом можно разобрать по этажам, пройтись по нему от первого лица и выгрузить в другие редакторы. Также к проекту можно подключить Codex и Claude Code и попросить ИИ создавать элементы здания.

TXORDER-01: 7 тестов прошли, 8-й нашёл баг

Как domain state в одном тесте сделал видимым баг в порядке операций внутри транзакции — и что это говорит о том, что на самом деле проверяют “зелёные тесты”

7 тестов прошли.

8-й нашёл баг в production flow.

Не потому что был написан лучше. Потому что запустился с другим начальным состоянием системы.

Операция и транзакция

PATCH /reschedule — перенос appointment пациента на другой слот. Атомарная транзакция: освободить старый слот, занять новый, переместить запись. Плюс promoteFromWaitlist: если на освобождённом слоте есть очередь, первый из неё автоматически получает appointment.

Порядок операций в транзакции:

1. free_old_slot(slot1)

2. promoteFromWaitlist(slot1)

3. book_new_slot(slot2)

4. move_appointment(appointment → slot2)

Почему 7 тестов ничего не нашли

Тесты 1–7 проверяли стандартные сценарии: перенести pending, перенести confirmed, попытаться перенести на занятый слот. Ни в одном из них не было пациента в вейтлисте.promoteFromWaitlist в каждом тесте — no-op. Очередь пуста, функция вызывалась, ничего не делала, возвращала успех. Это важная деталь: функция не падала. Она просто не активировалась. Порядок операций вокруг неё не имел значения — потому что одна из операций ничего не делала.

7 зелёных тестов говорили: reschedule работает корректно. На самом деле они говорили: reschedule работает корректно когда вейтлист пуст.

Что нашёл 8-й тест

Пациент 2 встал в очередь на slot1. Пациент 1 запустил reschedule на slot2.

Ответ: 409 SLOT_IN_USE.

Слот был свободен. Пациент имел право переноса. Транзакция откатилась.

Механизм

1. free_old_slot(slot1) ← слот доступен

2. promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1

3. book_new_slot(slot2)

4. move_appointment → slot2 ← appointment пациента 1 ещё на slot1

После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.

Транзакция дисциплинированно выполняла логически неверную последовательность — и откатывалась на constraint.

Фикс

Appointment должен покинуть slot1 до того как promote вставляет нового пациента:

1. book_new_slot(slot2)

2. move_appointment → slot2

3. free_old_slot(slot1)

4. promoteFromWaitlist(slot1)

8-й тест прошёл

Что означают 7 зелёных тестов

Тест проверяет поведение системы при конкретном начальном состоянии. Если в наборе тестов нет нужного domain state — класс ошибок невидим, сколько бы тестов ни прошло.

В данном случае критическое условие — пациент в вейтлисте — отсутствовало во всех семи тестах. promoteFromWaitlist` был no-op в каждом из них. Баг в порядке операций существовал с момента написания — просто не было состояния которое его активировало.

Атомарность транзакции гарантирует: либо все операции выполнятся, либо ни одна. Она не гарантирует что операции написаны в правильном порядке. Это разные гарантии — и мы путали их семь тестов подряд.

Скрытое предположение “Я решилf что если транзакция атомарна — порядок операций внутри неё можно не тестировать. На самом деле транзакция защищает от частичных обновлений, но не от логически неверного порядка внутри.”

Код проекта: GitHub

Из серии “Тихие отказы в тест-автоматизации” Разборы таких кейсов — в Telegram-канале Тесты как система

Про LLM и мир костылей

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

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

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

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

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

Регулярно пишу в Телеграм-канале Chief Philosophy Officer  и VK группе о философии бизнеса.

Биллинг — это не «простая логика». Четыре грабли за два года разработки

«Напишем за неделю, там простая логика» — так начинается каждая вторая история с биллингом. Через два года получаем систему, которую понимает один человек, пересчёты вручную и клиентов, которым непонятно, почему именно такая сумма. Разбираем типичные ошибки и что закладывать до первого клиента.

Проблема начинается с недооценки. Команда видит базовую математику: тариф × количество × период = счёт. На бумаге выглядит элементарно. В реальности через месяц появляются льготные периоды, через три — пересчёты при смене тарифа, через полгода — клиенты с индивидуальными условиями, которые не вписываются ни в одну модель.

Граблі №1: Отсутствие аудита изменений

Первое, что ломается — прозрачность расчётов. Клиент звонит с вопросом «почему 47 320 рублей, а не 45 000». Разработчик лезет в код, смотрит логи, пытается восстановить цепочку применённых правил. Если изменения тарифа или скидок не пишутся в отдельную таблицу с timestamp и причиной — готовьтесь к ручным разборам каждого спорного счёта.

Решение — event sourcing для биллинговых операций. Каждое изменение тарифа, применение скидки, пересчёт — отдельная запись с контекстом. Не нужен полноценный event store, достаточно таблицы billing_events с полями: timestamp, entity_id, operation_type, old_value, new_value, reason, author. Это база для автоматической генерации детализации и разбора конфликтов.

Граблі №2: Пересчёты при смене тарифа

Клиент переходит с тарифа A на тариф B в середине периода. Простая логика говорит: пропорционально разделить. Реальность добавляет нюансы: минимальный платёж по старому тарифу, неделимые единицы потребления, уже выставленный аванс. Без явной модели пропорционального расчёта получается хардкод под каждый кейс.

Закладывайте prorated billing с первого дня. Это не про сложную математику, а про чёткие правила: как считается остаток периода, как учитывается уже оплаченное, что делать с неделимыми единицами. Пропишите эти правила в коде явно, с комментариями и тестами на граничные случаи.

Граблі №3: Единственный человек, который понимает систему

Через год разработки логика биллинга живёт в голове одного разработчика. Он знает, почему вот этот if обрабатывает старых клиентов иначе, почему там hardcoded исключение для корпоративных аккаунтов и почему пересчёт запускается дважды для определённых тарифов. Документации нет, код читается как алгебра с магическими константами.

Биллинг — это не feature, это критическая инфраструктура. Требуется документация на уровне ADR: почему выбрана такая схема пересчёта, какие альтернативы рассматривались, какие trade-offs. Код должен быть самодокументируемым: явные named-константы для льготных периодов, enum для типов тарифов, отдельные функции для каждого правила расчёта.

Граблі №4: Нет разделения на фазы расчёта

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

Разделите расчёт на фазы: 1) сбор данных о потреблении, 2) применение правил тарификации, 3) применение скидок и льгот, 4) генерация счёта, 5) отправка клиенту. Каждая фаза — отдельная функция с чёткими входами и выходами. Это позволяет тестировать изолированно, пересчитывать отдельные этапы и логировать промежуточные результаты.

Что закладывать до первого клиента

• Аудит всех изменений: таблица событий с timestamp, контекстом и автором операции.

• Модель пропорционального расчёта: явные правила для смены тарифа, остатка периода, минимальных платежей.

• Разделение на фазы: сбор данных → тарификация → скидки → счёт → отправка. Каждая фаза изолирована и тестируема.

• Документация решений: ADR для ключевых правил, комментарии в коде для неочевидной логики.

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

TG @ciologia

Почему API переписывают через полгода и как этого избежать

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

Запуск нового сервиса обычно проходит в условиях жестких дедлайнов и давления бизнеса. Приоритет — скорость, архитектура API откладывается на потом. Результат предсказуем: через полгода структура эндпоинтов не вписывается в логику продукта, интеграции становятся хрупкими, документация расходится с кодом.

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

Что ломается первым

Отсутствие контракта между клиентом и сервером — главная причина хрупкости. Когда API проектируется по принципу «сделаем быстро, потом поправим», возникают системные проблемы:

• Эндпоинты перегружены логикой — один метод делает слишком много, изменить его без побочных эффектов невозможно.

• Структура данных меняется без версионирования — клиенты ломаются на продакшене после деплоя.

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

• Безопасность добавляется постфактум — авторизация, валидация и rate limiting наслаиваются хаотично, создавая дыры.

По данным исследования Postman State of the API 2023, 40% команд тратят больше времени на исправление проблем интеграции, чем на разработку новых функций. Основная причина — отсутствие контракта на этапе проектирования.

Как закладывать гибкость на старте

Системное проектирование API не означает месяцы планирования. Речь о базовых принципах, которые экономят время в будущем:

1. Определите схему данных до первой строки кода. OpenAPI, JSON Schema или Protocol Buffers — инструмент вторичен, важен контракт между клиентом и сервером. Схема становится единым источником истины и основой для автогенерации кода.

2. Версионируйте с первого дня. Даже если изменения пока не нужны, структура для версий (через URL, заголовки или content negotiation) должна быть заложена сразу. Переход на версионирование постфактум болезненен.

3. Проектируйте эндпоинты под бизнес-операции, а не под таблицы базы. CRUD удобен для прототипа, но быстро показывает ограничения. Операции вроде «подтвердить заказ» или «пересчитать баланс» должны быть явными методами, а не набором UPDATE-запросов.

4. Закладывайте безопасность в архитектуру. Авторизация, валидация входных данных, rate limiting и логирование — не опциональные доработки, а часть контракта. Добавление их потом ломает обратную совместимость и усложняет интеграции.

Trade-offs, о которых молчат

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

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

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

TG @ciologia

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

Другую забавную байку в комментах поведал аноним с одноразовым аккаунтом. Примерно десять лет назад товарищ анонима перешёл на работу в некий стартап в качестве технического директора. Дела у компании шли отлично, бизнес быстро рос, в команде было порядка 200 разработчиков.

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

Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.

Любая система всегда существует в двух основных контекстах: пользовательском и админском. Есть еще контекст ошибки, но сейчас не про него.
Контекст – это не домен, наоборот это часть домена.

Речь не только про разработку и ИТ.  Канализация, кран, автомобиль, самокат, футбольный мячик - это применимо к любой системе физического мира.

Это применимо к подсистемам: двигатель, коробка передач в автомобиле, каталог или система заказов в e-com.

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

К чему эта мысль?

Если для вашей системы внутри одного домена/поддомена нужно 2 админских или пользовательских контекста, то скорее всего у вас проблемы в архитектуре системы. 2 варианта:

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

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

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

Не дублируйте контексты для домена, это плохо кончится.

Паттерны проектирования еще актуальны?

Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?

У меня ощущение обратное.

Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.

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

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

Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.

Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.

Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?

Разрываем шаблоны: строим график с разрывом всего на 65 строк

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

Самые ходовые решения этой проблемы — разорванная ось (broken axis) или отдельные бины для аномалий. Проблема в том, что в Matplotlib нет готовой «кнопки» для создания гистограммы с разрывом. Но это легко* собирается руками на уровне нескольких осей.

Вот три рабочих подхода — выбирайте под свою задачу.

1. Официальный пример из документации Matplotlib. 🔗 Ссылка на гайд. Отлично работает, когда выбросы зашкаливают по одной оси (X или Y). В посте разбирается как раз такой случай: гистограмма с волнистой линией обрыва.

2. Библиотека brokenaxes делает почти всё сама. Устанавливается стандартно через pip. Вариант для тех, кто не хочет углубляться в ручную настройку.

3. Логарифмическая шкала (часто — самый простой выход) Если выбросы строго положительные и отличаются на порядки, иногда достаточно двух строк: plt.xscale(«log») или plt.yscale(«log»). Никаких разрывов, никакой ручной работы — при этом график остаётся чистым и читаемым.

import matplotlib.patches as mpatches
import matplotlib.pyplot as plt
import numpy as np
from matplotlib.path import Path


def plot_broken_axis(
    labels: list[str],
    values: tuple[float, ...],
    ylim_low=(0, 12),
    ylim_high=(20, 25),
    **kwargs,
):
    """
    Строит график с разрывом оси.
    Валидирует входные данные и инкапсулирует логику отрисовки.
    """
    if len(labels) != len(values):
        raise ValueError("Длины labels и values не совпадают")

    fig, (ax_high, ax_low) = plt.subplots(
        nrows=2, figsize=(7, 4), gridspec_kw={"height_ratios": [1, 2]}
    )

    # Настройки столбцов
    kwargs.setdefault("color", "skyblue")
    kwargs.setdefault("edgecolor", "black")
    kwargs.setdefault("alpha", 0.85)

    ax_low.bar(labels, values, **kwargs)
    ax_high.bar(labels, values, **kwargs)
    fig.subplots_adjust(hspace=0.0)

    # Настройка осей
    ax_low.set_ylim(*ylim_low)
    ax_high.set_ylim(*ylim_high)
    ax_high.set_title("График с разрывом")
    ax_low.set_ylabel("Рейтинг в %")
    ax_low.set_xlabel("Языки")
    ax_high.spines["bottom"].set_visible(False)
    ax_low.spines["top"].set_visible(False)
    ax_high.tick_params(axis="x", bottom=False, labelbottom=False)
    # Рисуем разрыв оси (волна)
    offset, n_points = 0.03, 33
    pts = np.linspace(-offset, 1 + offset, n_points)
    wave = np.array([1 + (0, offset, 0, -offset)[i % 4] for i in range(n_points)])
    path = Path(list(zip(pts, wave)), [Path.MOVETO] + [Path.CURVE3] * (n_points - 1))

    opts = dict(transform=ax_low.transAxes, clip_on=False, zorder=10)
    ax_low.add_patch(mpatches.PathPatch(path, lw=6, **opts))
    ax_low.add_patch(mpatches.PathPatch(path, lw=3, edgecolor="white", **opts))
    return fig


if __name__ == "__main__":
    langs = ["Python", "C", "C++", "Asm"]
    pops = (21.8, 11.1, 8.6, 1.1)

    # Стиль xkcd
    with plt.xkcd(scale=1, length=300, randomness=30):
        plt.rcParams["font.family"] = "Comic Sans MS"

        # Вызов функции
        fig = plot_broken_axis(langs, pops)
        plt.show()

Литература:

• Документация Matplotlib. 🔗 Ссылка на гайд

• Bernd Klein. Numerisches Python Arbeiten mit NumPy, Matplotlib und Pandas

• Sandro Tosi. Matplotlib for Python Developers

РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.

Цели восьмого процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Пара наблюдений (записанных наспех, извините) вокруг ситуации с ИИ:

1. ИИ умеет писать код, но плохо (= хуже, недостаточно хорошо) умеет поддерживать его. Почему же так? ИИ обучался на основе данных из Интернета. В Интернете очень много кода, но код — это результат процесса разработки. Процесс разработки во многом идёт «в головах» и «на бумаге» отображается редко и не полностью, в отличие от кода. Единственный (основной) источник знаний ИИ о процессах — разные статьи и тому подобное, объём их на порядки меньше объёма готового кода;

   1. То же самое с проектированием архитектуры систем;

   2. Из этого следует, что ИИ неплохо подходит для написания write‑only кода;

   3. Дежурные истины: сложность не всегда в написании кода. Часто/обычно она в его поддержке, развитии, интеграции, в анализе предметной области;

   4. ИИ тоже член команды. Если вы пишете напр. пет‑проект и все традиции оформления кода, именования объектов, ведения документации и тому подобное находятся в вашей голове, вам либо придётся как‑то их сформулировать, чтобы ИИ писал в том же стиле, либо терпеть чужеродно выглядящий код;

   5. ИИ плохо пишет то, по чему мало информации в Интернете;

      1. Наличие в том же Интернете документации не поможет;

      2. Не недооценивайте объём туториалов и готовых решений на Python'е;

2. При приведении в споре своего опыта работы с ИИ обязательно нужно указывать название модели;

   1. Научно‑технический прогресс измеряется по лучшим представителям;

   2. Вайб‑кодинг тоже бывает разного уровня профессионализма. Уровень более низкий: «написал (бесплатному) Дипсику, чтобы он сделал хорошо», уровень выше: «написал [такому‑то, более хорошему, ИИ], что нужно сделать, с чем интегрироваться, как оформлять, что выдать в ответе; перечитал запрос в поисках неточностей в ТЗ...», уровень выше: «использую плагин в IDE, стандартизировал некоторые требования» и тому подобное;

3. Текст, который выглядит, как написанный ИИ, написан либо ИИ, либо человеком, который (видимо) обчитался таких же текстов и перенял стиль;

   1. Как было раньше: если статья написана без орфографических ошибок и повествование более‑менее внятное (не как у меня ^_^), это значило, что автор хотя бы статью вычитал, спланировал, отредактировал и тому подобное, то есть вложил силы, потому что написать неграмотно и невнятно может каждый. Сейчас же ИИ пишут как раз таки грамотно, внятно и структурировано, то есть теперь для такого же результата силы вкладывать не нужно;

4. ИИ могут воспринимать рекомендации и явные разрешения что‑то делать как руководство к действию. Например, «допустимо использовать НазваниеБиблиотеки» резко повышает шанс того, что ИИ именно её и возьмёт;

5. В вопросе ИИ люди делятся на «философов» и «инструментальщиков». Характерные фразы первых: «чёткого определения интеллекта нет», «ИИ не AGI», «ИИ называть ИИ некорректно» и тому подобное. Часто из тезисов выше ими делается вывод, что всё, что называется ИИ — чепуха. «Инструментальщики» же не заботятся о том, что как называется, им ясно, что даже если ИИ не может делать всё, то он уже может делать много что, поэтому является полезным (как можете догадаться, позицию первых я не разделяю и считаю непродуктивной);

   1. Если где‑то из‑за замены ручного труда на труд ИИ упало качество производимого продукта, но использование ИИ не прекращается, это говорит плохо не об ИИ, а о потребителях продукта. Ибо спрос рождает предложение, и если он удовлетворяется контентом неприемлимо низкого качества (по вашему мнению), то так было бы и без ИИ;

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

Учимся писать промпты правильно

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

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

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

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

Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.

Поэтому сейчас я иду по такому пути. Включаю режим планирования и дальше даю короткое описание задачи и подробный контекст.

Для упавшего ci это выглядит так:

1. Поправь тесты

2. Прошу посмотреть последний запущенный билд на github actions

Баг в браузере:

1. прошу открыть страницу (он это делает через mcp chrome) и самому изучить

Для рефакторинга:

1. Переводим вот это на это

2. Вот эталон (тут ссылка на файл)

Для фичи:

1. Нужно реализовать такую фичу

2. Даю пример или говорю с помощью какого инструмента

И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.

Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.

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

В дружественном нам блоге "SSP-Soft" недавно вышла рецензия на изданную нами книгу «UX для бизнеса: как создавать цифровые решения, ценные для бизнеса и пользователей». Книга поднимает важные, но зачастую упускаемые вопросы, связанные с проектированием удобных сайтов и приложений. Как сделать интерфейс одновременно технологически надёжным, интуитивно понятным и при этом рассчитанным на целевую аудиторию? Как добиться, чтобы в интерфейсе было удобно быстро сориентироваться, но при этом не упускалось ничего важного? Наконец, как учесть в интерфейсе интересы всех, кто будет им пользоваться - от маркетолога и дата-аналитика до простого пользователя?

В книге раскрыты ключевые аспекты оценки ценности продукта, диагностики проблем и определения оптимальных путей развития проектов. Изложены методы принятия обоснованных решений на всех этапах жизненного цикла проекта — от идеи до реализации. Рассмотрены принципы проектирования интерфейсов, структур и продуктов для разных сфер — от простых интернет-магазинов до сложных экосистем. Описаны различные типы продуктов и сервисов, включая контент-тяжелые платформы,  программное обеспечение для бизнеса (SaaS/PaaS), социальные сети, игры и инструменты машинного обучения. Подробно рассмотрены подходы к оптимизации процессов дизайна, принятию приоритетов и организации взаимодействия внутри команды и с внешними заинтересованными сторонами.

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

С некоторым опозданием предлагаем вам почитать обзор на переведённую нами книгу Диего Пачеко и Сэма Сгро "Принципы модернизации программных архитектур". Обзор сделали в своём корпблоге специалисты дружественной нам компании SSP-Soft. Книга появилась в продаже в начале декабря, пока только бумажная версия.

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

Приятного чтения!

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

API First и Богатая доменная модель не являются взаимоисключающими понятиями, если правильно выстроить процесс и архитектуру.

Главная проблема: API First фокусируется на контрактах внешнего мира, что часто приводит к созданию DTO/Model классов, которые являются чистыми структурами данных без поведения (анемичная модель).

API First — это про контракты, а не про реализацию. Не позволяйте инструментам кодогенерации диктовать структуру вашей доменной модели!

Правильный workflow:

1. API Design First: Создайте/обновите OpenAPI спецификацию.

2. Генерация DTO: Сгенерируйте или создайте классы для API‑контрактов.

3. Projection First: Спроектируйте доменную модель независимо от DTO, фокусируясь на поведении и инвариантах.

4. Создание Mapping Layer: Напишите преобразователи между DTO и Domain Objects.

5. Реализация Application Service: Тонкий слой, который координирует работу домена.

Стек технологий, который помогает:

— MapStruct: Для автоматизации маппинга между DTO и Domain
— JUnit 5: Для тестирования доменной логики
— OpenAPI Generator: Для автоматической генерации DTO из спецификации
— ArchUnit: Для проверки архитектурных правил (например, запрет на анемичные модели)

// ArchUnit тест, проверяющий, что в доменных классах есть поведение
@ArchTest
static final ArchRule domain_models_should_have_business_methods = 
    classes()
        .that().resideInPackage("..domain..")
        .and().areAnnotatedWith(Entity.class)
        .should().containAnyMethodsThat(
            DescribedPredicate.describe(
                "have business methods", 
                method -> !method.getName().startsWith("get") && 
                         !method.getName().startsWith("set")
            )
        );