Привет! Меня зовут Михаил, я Senior Software Developer в YouHodler.

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

Нежданная проблема

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

Одной из зон интереса аудитора, скорее всего, была именно система этих договоры, в контексте тех продуктов которые уже были открыты пользователями. Для себя мы сформулировали возможный запрос следующим образом: «Дайте мне, пожалуйста, договор по продукту A, на дату B, для пользователя из страны C».

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

В результате могла возникнуть ситуация, когда был сгенерирован документ для юридического лица, которое не было создано на момент открытия продукта. Качество кода давало понять, что это далеко не первый внезапный визит аудитора, т. е. никто не понимал как (и почему) это работает.

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

В результате мы приняли давно назревшее решение о создании нового микросервиса. Данный сервис должен был уметь связываться с десятком других микросервисов, получать от них объекты продуктов, приводить их к похожему виду, а затем с помощью выбранного темплейта вставлять плейсхолдеры и выдавать пользователю готовый PDF. Не rocket science, конечно, но объемный эпик с кучей монотонных и рутинных задач.

Цейтнот

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

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

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

Я приступил к созданию boiler plate. Обычно на этом этапе любой менеджер пытается ускорить процесс и ставит несколько встреч в день для контроля. Однако у меня получилось отказаться от этого «замечательного» предложения, так что я свел количество любых собраний практически к нулю чтобы меня ничего не отвлекало.

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

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

Создав общий флоу, а также алгоритм конфигурирования выбора нужного темплейта, я приступил к работе с самым первым документом. Это был один из самых старых документов в нашей компании.

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

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

Команда, assemble!

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

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

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

Для подключения к контейнерам с продуктовыми сервисам я использовал Telepresence, поэтому работал локально с реальными, а не смоделированными или искуственными данными, что в конечном счете сильно упростило тестирование.

Очень важно было постоянно поддерживать коммуникацию с другими членами командами. Аналитикам были делегированы все вопросы по уточнению нюансов работы, тестеры оперативно брали в работу готовые модули и приходили с обратной связью. С продукт-оунером договорились, что в первой итерации мы будем предоставлять документы только в admin panel, а пользователи будут генерировать их на старом флоу. Несмотря на все это, работать приходилось по 12–14 часов в день.

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

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

Важные уроки

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

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

Овертайм в IT — это повсеместное явление. Мы работаем со сложными системами, и задачи сами по себе сложны в оценке. Главное, чтобы овертайм не стал ежедневной рутиной. Постоянный прессинг со стороны дедлайнов и стейкхолдеров — один из самых быстрых способов выгореть.

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

Спасибо за внимание! Надеюсь, моя история показалась вам интересной и полезной. А тем, кто интересуется разработкой, я хочу порекомендовать курсы от компании ProductStar. Опытные менторы научат вас с нуля работать по направлениям Python, Java и Frontend.