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

Эксперт по DDD пытается помочь команде тонущего проекта 🙂)

Признаться, раньше не слышал про https://mockintosh.io/ . Многим он подойдет лучше, чем Mountebank или WireMock, учитывая, что тестировщикам ближе Python. Правда, давненько коммитов уже не было.

Что используете вы для изоляции тестовой среды сервиса?

Вот такое народное творчество крупных ИТ-корпораций присылают мне в личку (публикуется с согласия собеседника).

Песнь про менеджера среднего звена:

В корпорации, среди стен,
Там, где свет не проникает совсем,
Жил был зверь, пугающий всех злобно,
Не конь-людоед, а глист-каннибал.

Он ползет, сверкают глаза,
Песня о нем страшна и грозна.
Видно, судьба у нас такова,
Бойтесь его, глиста-каннибала!

В корпорациях, среди стен,
Где умирает дух перемен,
Там, где таблицы скрывают пороки,
В правде своей мы одиноки

Не конь-людоед, а глист-каннибал,
Тихо ползёт, как ночь, как финал,
Сияют экраны, но пустота,
Власть здесь у тех, кто ест изнутра.

Корпорации строят из стали капканы,
Люди – просто энергия, планы.
А глист-каннибал, он не спит никогда,
Его миссия: жрать. Это навсегда.

И где-то в углу, в чёрной тени,
Горит монитор, мерцают огни.
Ты думаешь, выжил, но слышен сигнал:
"Иди ко мне, я глист-каннибал!"

Что я увидел здесь с управленческой точки зрения:

Где умирает дух перемен,

1. Отсутствие адаптации в модели разработки, т.е. итеративно-инкрементальная модель разработки не достигает своей цели. Это при том, что данная конкретная корпорация считает себя флагманом индустрии во внедрению Agile.

Там, где таблицы скрывают пороки,

Люди – просто энергия, планы.

2. Уклон в сторону проектных практик в ущерб продуктовым.

В правде своей мы одиноки

Власть здесь у тех, кто ест изнутра

3. Несбалансированное принятие технических решений, игнорирование интересов технической группы стейкхолдеров.

пугающий всех злобно

4. Прогрессирование страхов сторон разработки, т.е. цель Agile снова не достигнута (см. со слов "Software development is risky. People involved have many fears of what may go wrong" здесь).

Лично я отношусь к такому творчеству как к источнику ценной информации о наболевших системных проблемах.

Очень интересна неоднозначная реакция на предыдущие посты. Хотя описанное явление известно под названием "Larman's Laws of Organizational Behavior".

Gregor Hohpe описывал это в статье "Reversing the disablement cycle: Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits."

И есть очень качественный русскоязычный ресурс по этой теме: "Что такое сопротивление изменениям и как с ним работать?"

На эту тему у меня была заметка о том, как осуществлять изменения в коллективе.

С днем рождения меня, дорогой! 🍾🎂🥂🎇🎊🎉
https://news.1rj.ru/str/emacsway/s/6

💬 "Как только мы почувствовали гнев во время спора, мы уже спорим не за истину, а за себя." -- Карлейль

Найдена уникальная цитата, предположительно способная пробудить интерес юниоров к чтению. Не пробовал на практике, если кто попробует - поделитесь результатом, пожалуйста.

💬 „Всем известно, как тихи кладбища. Библиотека – самое веселое из них. Тут уж покойники в полном составе: они не сделали ничего плохого, лишь писали… От книги исходит аромат склепа. Вот тут начинается странный процесс, которую он называет чтением. С одной стороны, это обретение: он передает свое тело мертвым, чтобы они могли ожить. С другой – это общение с потусторонним миром.“ — Жан-Поль Сартр

Источник: https://ru.citaty.net/tsitaty/641057-zhan-pol-sartr-vsem-izvestno-kak-tikhi-kladbishcha-biblioteka-sam/

Как любил повторять один известный исторический деятель - «короче», «яснее». Вот это видео очень хорошо демонстрирует этот принцип:
https://vt.tiktok.com/ZS62A4GXs/

Примерно так же должен изъясняться и архитектор. Обратите внимание на отсыл к Закону Миллера в этом видео, и на акцент на визуализацию.

Рассчитывал на Locust, но обнаружил, что asyncio там не поддерживается и его поддержка пока не предвидится.

Нашелся нагрузочный микро-движок, который выручил: https://molotov.readthedocs.io/

После двух лет забвения по причине личных обстоятельств, наконец-то возвращаюсь к привнесению общественно-профессиональной пользы.

17 января совместно с командой закончил работу над созданием нагрузочного фреймворка для микросервисов, аналоги которого мне неизвестны (иначе я бы их применил).

Началось все с создания генератора объема фейковых данных (см. здесь и здесь) для микросервисов, который воспроизводил бы селективность индексов как в целевой системе.

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

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

Поддерживается логика многоступенчатого создания агрегата (black-box), когда агрегат возможно привести в необходимое состояние только серией запросов через public API.

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

Конечно, писать свой ORM архитектору может и нет практической необходимости, но в чем я сейчас твердо убежден, так это в том, что успешность архитектора немыслима без нагрузочных fitness-functions. А там практические навыки применения PoEAA оказываются на вес золота, независимо от того, создаете ли вы ORM или генератор фейковых данных. И наивно полагать, что эта задача посильна рядовому программисту. Если вдруг где-то специалисты с такими навыками и засиделись на позиции программиста, то будьте уверены - долго они на этой позиции в такой компании не задержатся. Это к вопросу о том, должен ли уметь архитектор в код.

Вскоре мы обнаружили, что полученный генератор данных можно использовать и для нагрузочных тестов. Адаптировали его для работы с публичным API (вместо прямого доступа к БД), сделали поддержку multiprocess.

Интегрировали его с нагрузочным движком molotov. Изначально рассчитывали на Locust, но обнаружили, что asyncio там не поддерживается и его поддержка пока не предвидится. Позже я узнал от @nkhitrov, что решение все-таки есть.

Потом мы обнаружили, что полученное решение можно без труда использовать для Out-of-process Component (Acceptance) Testing.

Таким образом, нам удалось сделать тестовый фреймворк (на Python), который позволяет одновременно и генерировать фэйковые объемы данных, включая автоматическое создание всех зависимых объектов, и создавать нагрузочные скрипты, и выполнять component out-of-process tests.

Теперь хотим завернуть его в Gherkin, чтобы fitness-functions в нем описывать. И добавить декларативное описание моделей посредством YAML-file.

Свои функции он уже выполняет. На текущий момент исходный код проприетарен. В перспективе возможно его раскрытие (обсуждается с владельцем кодовой базы) или оказание услуг нагрузочного тестирования сторонним ИТ-компаниям.

Работаем!

Может кому-нибудь пригодится для Out-of-process Component (Acceptance) Testing:
https://github.com/litestar-org/polyfactory

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

Добавил поддержку Gherkin для реализации Fitness-Functions в Performance Framework. Теперь описание Fitness-Function выглядит примерно так:

  Scenario: Some object endpoint name
    Given SUT with 10000000 objects
    When 100 processes created 10000 objects each
    Then average RPS is greater than 1000
    And error rate is less than 5%

Реализация подобного сценария посредством behave с использованием Performance Framework занимает всего 40 строк кода (половина из которых - это пустые строки и переносы строк для форматирования). Все зависимые объекты в БД создаются автоматически с сохранением селективности индексов целевой системы (включая индексы внешних ключей зависимых объектов). Подробная статистика запросов накапливается на сервере статистики. В перспективе, при наличии благоприятной возможности, может быть добавлена поддержка декларирования вероятностной распределенности зависимых объектов и проиндексированных значений непосредственно в Gherkin-спецификации.

Материала по этой теме накопилось на полноценный доклад (если даже не на целую книгу). Подумаю об этом.

Eще несколько решений, способных облегчить Out-of-process Component (Acceptance) Testing:
- https://schemathesis.readthedocs.io/
- https://hypothesis.readthedocs.io/
- https://github.com/python-jsonschema/hypothesis-jsonschema
- https://pypi.org/project/hypothesis-sqlalchemy/
- https://dredd.org/