Совсем недавно наша аналитик рассказывала о том, как выиграть хакатон, сохранив моральное и физическое здоровье.

За пару дней до выхода статьи эта же аналитик подговорила наших ребят участвовать в командном хакатоне. Результат не самый приятный — 38 место из 60. Однако, этот опыт, как и любой другой, не прошел даром (а еще был очень веселым).

В этой статье каждый участник команды поделится своим опытом и персональной рефлексией. Ну и лулзами, пойманными в процессе.

Немного о самом хакатоне

Это снова был хакатон Совкомбанка — Sovcombank Team Challenge 2022.

Примечание: аналитик плотно сидит на хакатонах этих ребят, поэтому да, опять Совкомбанк =)
Подробная информация доступна на сайте соревнования.

Задача звучала следующим образом:

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

Необходимый функционал приложения:

• Ролевая модель (пользователь и администратор приложения, необходимы интерфейсы для каждой роли).

• Функционал регистрации новых пользователей (в рамках процесса регистрации создается первый рублевый счет для торговли).

• Функционал подтверждения регистрации для администратора приложения.

• Функционал для блокировки/разблокировки пользователей.

• Функционал для пополнения и выведения средств с рублевого счета.

• Функционал открытия нового счета для проведения операций над выбранной пользователем валютой.

• Отображение сводной информации по имеющимся в портфеле пользователя активам. Состав представленной информации должен быть обоснован.

• Отображение исторической информации о движении валюты (отчет по сделанным операциям).

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

• Функционал торговли, возможность покупать и продавать валюту по рыночному курсу (курс из внешнего источника).

• Визуализация графика стоимости валюты/валют за период (график изменения стоимости).

• Расчет и визуализация прогнозной стоимости валют(технический анализ, регрессионные модели, ML и т.д.).

Критерии оценки:

• Понятный и размеченный Readme для функционала.

• Структура проекта в GitLab/Github.

• Архитектура проекта.

• Качество back-end решения.

• Качество front-end решения .Реализация ролевой модели (технический администратор, пользователь) и функционал регистрации.

• Полнота реализованной функциональности.

• Реализован и обоснован функционал прогноза стоимости актива.

• Безопасность приложения.

• Креативность решения.

Что надо было сдать жюри:

• Презентацию решения.

• Ссылку на репозиторий.

• Ссылку на прототип решения, если доступен не только локально.

О составе команды

Наша команда называлась «Нарвал ушел в Астрал» и состояла из 4 человек:

• backend-разработчик (STM Labs)

• fullstack-разработчик

• DevOps-специалист (STM Labs)

• системный аналитик (STM Labs)

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

Системный аналитик на кодерском хакатоне — пятая нога для собаки?

Как, зачем, почему?

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

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

Давайте попробую разложить выученные мной уроки по полочкам :)

Умение выкручиваться

Оказалось, у меня, как у аналитика, встроено неплохое умение выкручиваться из плохих ситуаций :)

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

Не успеваем сделать интерфейс администратора? Мы же используем KeyCloack, у которого есть веб-морда, объявляем его админкой!

Нет системы, способной отдавать курс валюты приемлемо быстро? Придумываем такую систему, внутри которой эмулируем поведение курса валют через алгоритм случайных блужданий!

И так было весь хакатон :D Честно, мой мозг еще никогда не искал столько аварийных выходов и еще с такой скоростью. Было очень приятно осознавать, что горшочек-то, оказывается, варит =)

Системный аналитик — полезный игрок

Где-то уже в районе подведения итогов в чате соревнования проскользнуло сообщение «а что у вас в команде делал аналитик, если он не успел сделать хорошую презентацию?»

Даже как-то обидно за нас стало :D Лично я в первый день хакатона с 19:30 до 2-х часов ночи сидела в офисе и:

• искала аварийные выходы, чтобы и функционала побольше обеспечить, и не играть снова в героев недосыпа;

• рисовала архитектуру;

• прикидывала контракты взаимодействия front-back;

• определяла роадмап, чтобы на каждом последующем шаге у нас было работающее решение;

• раскидывала последовательность задачек для ребят.

В последующие два дня я затыкала максимально все дырки, которые могла заткнуть. Была и дизайнером, и специалистом по Google, и менеджером по заказу еды и завариванию чаечка… Кем только не была. 

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

Правда мы все равно ничего не успели, но об этом далее :D

Нецелевое использование игроков команды

Вот честно, настаивать, чтобы программист кодил фронт на React, на котором он никогда не кодил (потому что jQuery — это не модно!) было МАКСИМАЛЬНО не годной идеей :D

В следующий раз мне будет абсолютно наплевать, что модно, а что нет. Если у меня есть хороший специалист, которого я сама позвала в команду — нужно использовать его сильные стороны. «Немодный» jQuery? Come on, ты аналитик, вот и продай, почему именно он!

Таки да, я тот аналитик, что не успел в презентацию

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

Господи, в следующий раз я начну делать эту презентацию за неделю до хакатона!

Экспериментировать на хакатоне — удел гениев и сумасшедших

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

Что же мы решили?

В смысле,зачем использовать исследованное и наработанное?

Только эксперименты, только хардкор! :D *смеется и плачет*

Итого (в поддержку предыдущей статьи): хотите хорошо похакатонить — найдите время, в том числе — желательно и до хакатона тоже.

Дебагать прод не вовремя

Когда мы сдали решение, то обнаружили, что у нас, кхм, как бы это сказать… Не работает логин ????

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

У нас была нарушена сетевая связность компонентов, хотя локально у ребят все работало. Починить-то мы починили, но было уже поздно.

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

Сухой итог

Считаю наше решение хорошо теоретически проработанным, но реализация неумолимо опустила нас на 38 место. 

DevOps-специалист: успеть объять необъятное, или как нацелиться на большой воздушный замок и построить в итоге деревянный сарай 

Как, зачем, почему?

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

Далее, я тоже постараюсь рассказать о своих наблюдениях.

Хладнокровие

Как бы то ни было, в таких делах хладнокровие — одно из самых важных качеств. Как мне показалось, я был достаточно хладнокровен во время хакатона, но остальные могут со мной не согласиться (хе-хе)

Почему я сделал такой вывод? Потому что даже зная, что делайн остался за горизонтом, я не остановился, а закончил стенд.

Приспособляемость

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

Готовь сани летом

Казалось бы в том, что нужно готовиться заранее, нет ничего инновационного, но есть один нюанс. Минимальная работа DevOps’а в данной ситуации заключается в создании полностью работоспособного стенда для показа жюри, а потом уже настройка CI-инструментов и прочего.В данной ситуации в этом заключается самая важная часть работы, потому что отладить приложение, собранное «на коленке» — задача не из простых. Лучше уж вся обвязка будет готова заранее, чтобы на отладку осталось больше времени, ну или оно вообще осталось хотя бы. Потому что если приложение не отлажено, значит, что показывать нечего и DevOps работал впустую.

Нужно больше опыта

Иногда мне казалось, что для участия  в таких мероприятиях, нужно чуть больше опыта. Всегда что-нибудь да выплывет и разбираться в новой технологии в совсем короткое время — история не про хакатоны. И если бы всё сложилось еще хуже в ходе настройки и установки компонентов, то я бы был бесполезен. Хотя, с другой стороны — нельзя быть к чему-то готовым на 100%.

DevOps — нужен ли?

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

Fullstack-разработчик — фронтендер по воле аналитика

От хакатона мне хотелось нескольких вещей:

• перенять опыт разработки production-кода на React (что такое Effector, и с чем его едят, как такое удовольствие интегрировать с Backend’ом и т.п.);

• попробовать себя в разработке прямо-таки фронтового фронта;

• получить рабочую систему и изучить ее со всех сторон;

• завести себе облако (в котором опытный девопс развернет систему - а я смогу проанализировать его практики);

• затестить работу в команде промышленной разработки (сам я работаю в научной сфере, которая кардинально отличается от всего вот этого вот =) );

• выиграть денешку;

• познакомиться с ребятами (теперь могу мучать вопросами девопса и бэкендера).

Хороший аналитик - всему голова

В процессе разработки мы решили опираться на best practices, принятые в STM Labs. Я единственный в команде, кто являлся «внешним» разработчиком. Проще говоря, я в глаза не видел этих практик, и столкнулся с ними непосредственно в процессе разработки. В процессе разработки фронта на React, на котором я никогда не кодил. Поскольку у нас была аналитик, которая все эти практики проходила вдоль и поперек в разных вариантах и хорошо ориентировалась в них, задачу получалось решить не за час, а за 3 минуты :D

Команда решает, если это и правда команда

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

Ответственность, предел возможностей и сделка с совестью

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

Неплохо бы иметь заначку

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

React за два дня — быть или не быть

Вот краткая программа курса «Фронтенд на React за два дня с нуля без регистрации и смс»:

• делаем новые компоненты;

• вставляем svg, которые перекрашиваются из-за скрытых настроек (отчаиваемся, местами вставляем png);

• управляем состоянием приложения на фронте с помощью Effector: перенаправляем потоки данных с сервера в приложение, преобразуем данные, визуализируем;

• тыкаем в бэк POSTами и GETами через Axios;

• организуем иерархичный код: модели данных, типы данных, веб-страницы, компоненты, обращение к API, etc;

• билдим приложение через Node.js в docker, выгружаем это в docker-hub;

• связываем фронт с бэком локально;

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

Сложно ли мне было разбираться в React за два дня с нуля?

Не могу сказать, что я «разобрался». Но получил определенный, точно полезный, опыт. Мы сделали достаточное количество страниц, хотя исходно я рассчитывал, что хорошо, если будет логин :D

Но даже аналитик спасает не всегда

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

Хочешь выстрелить себе в ногу, пиши фронт через VNC

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

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

Позднее тестирование — this is fine

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

Backend-разработчик — с лопатой или на экскаваторе?

А оно мне надо?

Да-да-да, ребята, это полезно для саморазвития, проверка своих способностей — без стандартных фраз никуда. Но есть много людей, которые все прекрасно это понимают и спокойно живут в рабочем потоке, среди них  и я. Творческий подход, продуманность, красота — те вещи, которые мне нравятся и хочется использовать при решении задач, а на работе с этим еще и помогают: советуют, направляют, дают время. И вот когда предлагают поучаствовать в таком мероприятии, становится как-то неуютно: а действительно ли ты можешь быть на уровне, в том числе и в своей команде (в свои 30 годиков-то). Спасибо, что Настя раскачала мою лодку, нырнул, но там мелко.

 Сказали вскопать грядки… побежал за экскаватором

Знакомые решения — это конечно хорошо, и уверенность в них есть. Тем более нужно быть осторожным, когдау нас есть связка — время/требования. Не стоит тащить сразу все наработки, как сделал я. «Ой, Node.JS же быстрая и библиотеки хорошие, с Keycloak просто общаться будет, а основную обработку в отдельный Python-сервис вынести, там как-то привычнее с MongoDB общаться будет!» Стоило бы схлопнуть это в один Python-сервис с FastAPI и жизнь была проще. Хотя опыт опыту рознь конечно.

Экскаватор пригнали, надеваем каски и костюмы

Нужно быть проще. Естественно, в меру. По ходу движения работают инстинкты порядочного разработчика: схемы валидации, документирование, красивые комментарии в коде, шаблоны для коллекций в БД и т.п. Но до оценки такой красоты дело не дойдет, если приложение ничего не показывает. Поэтому можно уйти уже в другую крайность — «главное чтобы работало». Начинаешь торопиться и не замечаешь ошибки, которые рассыпал на предыдущих шагах. Токен не обновляется? Пфф выкручиваем время жизни сессии на 6 часов.

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

Глушим экскаватор

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

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

 Смотрим на другие грядки

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

Подводим итоги

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

1. Готовиться заранее — изучить все, что может пригодиться, а не спешно гуглить в процессе.

2. По возможности обеспечить сыгранность команды — это лучше чем набор разных специалистов.

3. Проверить технику — производительность ноутов, скорость интернета и т.д. — чтобы технические детали не тормозили процесс.

4. Морально подготовиться к затыканию дыр с помощью нестандартных решений

5. Грамотно распределять время: вовремя готовить презентацию, начинать тестировать и отлаживать приложение.

6. По максимуму использовать навыки и знания участников, а не экспериментировать с незнакомыми технологиями.

7. В первую очередь обеспечить работоспособность решения и только потом добавлять фичи.

8. Лучше выбрать простое, но рабочее решение, чем модное и изящное, но с костылями и изолентой.

9. Сохранять спокойствие и сосредоточенность, получать удовольствие и даже веселиться, а не поддаваться панике.

10. Ну и как обычно, беречь кукуху — не забывать спать, есть и отдыхать.

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

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