Как показать сферического коня в вакууме

Предыстория

Когда меня просят описать тенденцию последних 3 лет одним словом, то нейронные связи сразу генерируют: микросервисы. Да, в большинстве случаев под этим определением многие скрывают распределенные монолиты и запрещают произносить данное словосочетание вслух, но сегодня не об этом. И если в 2021 году в основном говорили об уходе от legacy систем, то в последнее время появился серьезный вектор политики импортозамещения.

Казалось бы, новые технологии и новые подходы — это ли не мечта любого разработчика? Вот только есть одно большое “НО”, которое часто объединяет разные банки общей концепцией. Сперва на уровне высокого руководства определяется срок вывода существующей системы из эксплуатации, а потом начинается набор тех самых “счастливчиков”, которые начинают играть в игру “главное не нам стать крайними в срыве нереальных сроков”.

Аналитики потом догонят!

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

Когда “костлявая компания” уже в сборе, то происходит переход к фазе “вы же специалисты, начинайте реализовывать очевидную логику”. Часто не забывая упомянуть, что у нас не какой-нибудь waterfall, так что не стоит ждать сформированных требований. Они, конечно, появятся, но позже. Такие догонялки могут затянуться надолго. И все это обычно сопровождается бесконечными вопросами и рассказами об уже реализованных кейсах.

Где хоть одна кнопка?

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

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

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

Как понять, что оно работает…

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

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

Пытаемся убить двух… То есть снизить влияние трёх зайцев одним выстрелом.

BDD — Behavior-Driven Development — разработка через поведение.

С данным подходом ранее довелось столкнуться на практике в 2014 году. Только тогда я еще не знал слово “микросервисы” и участвовал в разработке набора приложений на PHP для автоматизации работы дилеров автомобилей. И в те времена было принято постоянно говорить про какие-то “облака”.

Шаг первый. Выбор инструмента.

На основании нескольких страниц поиска был сформирован список из 15 инструментов.

А критериями отбора стали:

• Язык программирования на котором разработан сам инструмент, чтобы минимизировать сложность внедрения и поддержки
• Открытость исходного кода и возможность использования в закрытом коммерческом продукте
• Актуальность инструмента и его развитие
• Максимально понятный формат сценариев для всех участников команды

Как видно из таблицы, удовлетворить такому набору критериев смогли два варианта: Cucumber и JBehave. В целом, именно эту же пару зачастую можно встретить в различных сравнениях актуальных инструментов.

Но Cucumber JVM выглядел более перспективным в части собственного развития и документации, поэтому решили остановиться на нём. При этом он не только обладает хорошей интеграцией с актуальным стеком в рамках Java: Maven, Junit, Spring Boot, но и имеет реализации на десятке других языков: Node.js, Ruby, Lua, Android, Kotlin, Scala, Go, Python, C#, Rust. Это значительно увеличивает шансы найма в команду специалистов, которым ранее довелось с ним работать. Ну и дополнительным аргументом является не просто поддержка синтаксиса Gherkin, но и его локализация на русский язык из коробки.

Шаг второй. Внедрение.

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

Сама система представляла собой набор микросервисов на Spring Boot 2, с хореографией через различные события в топиках Kafka. Практически весь процесс был декомпозирован на логические транзакции, которые начинались с чтения интересующих событий из потока и заканчивались порождением новых.

Разработчики оценили идею, что вместо написания скучного кода для DTO или JSON, можно просто писать: «Допустим есть черновик платежа на сумму 50000 рублей». При этом многократно переиспользовать в разных сценариях ранее реализованные шаги, заменяя только значение отдельных переменных. А поддержка автодополнения в редакторе кода значительно упрощает этот процесс.

Шаг третий. Перейти от рассказа про коня к его показу.

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

Послесловие.

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

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