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

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

Откуда же эту информацию мы можем выдать? Достоверная оперативная информация о товарных остатках в Рив Гош распределена по разным OLTP системам: часть магазинов в современной централизованной 1С ERP управление холдингом, остальные магазины – в специализированных базах Oracle, распределительные центры – в 1С УПП. Единого оперативного хранилища нет.

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

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.

В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.

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

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

Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.

Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.

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

Синтаксический анализатор на стеках и lambda-выражениях (Axolotl)

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

Алгоритм синтаксического анализа кода на основе Shunting Yard

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

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

Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.

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

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

Чтоб избежать проверенного классического сценария «много, дорого, бестолково» нужны ориентиры. Пунктир намеченного пути на карте требований и функционала. Это не красота и элегантность рисунков Леонардо, и не лабиринты цвета Поллока. Архитектура вообще не про искусство. Нет, все любят, когда красиво. Вот я бы строил дом, тоже бы хотел не бетонную коробку, а чтоб в вечность. Но у вечности, однако свои расценки. Так что даже Джи-мэн с кейсом полным золота хочет хайп и тренды, но строго в бюджет. Архитектура даёт парадигму.

В прошлом году к нам обратился ИТ-директор одного из крупнейших аграрно-промышленных холдингов в России. Подход к бизнесу, который реализовал наш клиент, был впечатляющим. Он одним из первых реализовал идею предприятия полного цикла – от поля до полки в продуктовом магазине. Благодаря доступности и высокому качеству продукции этот холдинг стал признанным брендом, который знают и выбирают. В тот момент в холдинг входило более 650 торговых точек и более 20 000 сотрудников, распределенных по всей территории РФ.

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

С учетом указанной специфики решение задачи превратилось в увлекательное приключение с бубном, шаманами и кроличьими лапками в лице RabbitMQ. Как мы строили федеративный кластер очередей и с чем столкнулись – под катом.