Як це — бути розробником в Intellias - Mainacademy

Як це — бути розробником в Intellias

  • date_range 13 серпня
  • face Оля Паламарчук
  • chat_bubble_outline 0

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/