Как это — быть разработчиком в Intellias

Main Academy сотрудничает с топовыми компаниями, чтобы заботливо трудоустроить своих выпускников. Среди них Intellias — их HR проводит тренерские занятия для наших студентов.

Тарас Кльоба со Львова, BI Team Lead на проекте EveryMatrix, рассказывает как это — быть разработчиком в аутсорсинговой компании с тысячей работников.

— Расскажите о вашей команде и о том, над чем вы работаете?

Мы совместно с заказчиком разрабатываем высоконагруженных SaaS iGaming платформу, моделируем системы анализа и отчетности, менеджмент рисков, начисления бонусов, а также создаем конфигурируемых Front-end и мобильные интерфейсы.

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

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

— Можно работать удаленно? 

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

— Какие инструменты разработки используются в вашей компании? На каких языках программирования пишут разработчики?

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

Очередь сообщений реализована на кластере Apache Kafka, которые мы прорабатываем с помощью Talend ETL и Python-скриптов. Для построения отчетов и Ad-hoc запросов используем JasperReport Server.

Работаем над миграцией наших потоков данных на Google Cloud. В частности, в качестве хранилища данных будет использоваться Google BigQuery. Очередь сообщений будет организована с помощью сервиса Google Pub / Sub. Типичные ETL будут заменены на Google DataFlow. Такой переход существенно расширит наши возможности и позволит больше концентрироваться на бизнес-ценности.

— Как выглядит процесс разработки, жизненный цикл продукта?

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

Вообще наша команда работает по методологии Scrum. У нас есть спринты, ежедневные стендапы, груминг, планирование, сторипоинты и тому подобное. Компания-заказчик работает по методологии SAFe.

— Как принято проводить код ревью?

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

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

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

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

— Как принято проводить тестирование, какие тесты применяете?

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

— Как происходит развертывание (деплой)?

Мы внедрили Continuous Database Deployment процесс на нашем проекте. Это позволяет после каждого сохранения изменений в репозитории автоматически проводить тестирование базовой функциональности, иметь полностью синхронизированы изменения на всех средах, делать это централизованно в панели GitLab CI / CD, получать возможность аудита каждой смены и видеть результаты и успешность каждого деплойменту.

— Как проходит типичный рабочий день разработчика вашей команды? Сколько часов в день работаете?

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

— Как устроена коммуникация с заказчиком — непосредственно или через менеджеров?

В рамках нашего проекта мы общаемся непосредственно с заказчиком.

— Что делает вашу компанию особым местом для разработчиков? Какие плюсы и минусы?

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

Минусы: отсутствие собственных проектов.

Источник: https://dou.ua/lenta/articles/how-is-to-be-a-dev-1/