«Як це — бути розробником в... »— це нова рубрика, у якій ми запрошуємо представників різних компаній розказати про їхні проекти, особливості розробки та робоче середовище.
Intellias
— Розкажіть про вашу команду і про те, над чим ви працюєте?
Ми спільно із замовником розробляємо високонавантажену SaaS iGaming платформу, моделюємо системи аналізу та звітування, менеджмент ризиків, нарахування бонусів, а також створюємо конфігурабельні Front-end та мобільні інтерфейси.
Конкретно наша команда будує сховище даних, яке обробляє сотні гігабайтів даних: десятки мільйонів транзакцій кожного дня. Воно дозволяє за лічені секунди отримувати необхідні дані, на основі яких можливо приймати бізнес-рішення.
У нашій команді 10 людей, серед них немає розробників рівнем нижче Senior. Це дає низку переваг. По-перше, витрачаємо менше часу на пояснення складних процесів. По-друге, є довіра до якості роботи колег — я розумію, що завдання, за яке береться колега, буде реалізовано, і його не доведеться переробляти.
Декілька моїх колег — це люди, з якими я працюю разом понад 5 років.
— Які інструменти розробки використовують у вашій компанії? На яких мовах програмування пишуть розробники?
На нашому проекті основним сховищем даних є PostgreSQL, у якому ми зберігаємо терабайти даних. Ми використовуємо
Черга повідомлень реалізована на кластері 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 годин на день.
— Як влаштована комунікація з замовником — безпосередньо або через менеджерів?
У межах нашого проекту ми спілкуємося безпосередньо із замовником.
— Що робить вашу компанію особливим місцем для розробників? Які є плюси і мінуси?
Плюси: хліб із маслом і джемом, чудова кава, масаж в офісі, безкоштовні заняття з англійської та німецької, хороший сучасний офіс, чудові корпоративи, а також 20 днів оплачуваної відпустки та 15 днів оплачуваних лікарняних.
Мінуси: відсутність власних проектів.
Genesis
— Розкажіть про вашу команду і про те, над чим ви працюєте?
Загалом у команді нашого проекту SocialTech працює 60 спеціалістів: розробники, продуктологи та маркетологи.
У команді розробки — 32 людини, і ми постійно шукаємосильних спеціалістів. У нас є розподіл на продуктовий та маркетинговий відділи. Також є інфраструктурна команда, яка моніторить і слідкує за вправною роботою серверів, архітектурою мікросервісів, надає іншим командам рекомендації.
Ми працюємо в індустрії Social Discovery, де розвиваємо власні продукти, якими користуються мільйони людей по всьому світу.
— Які інструменти розробки використовують у вашій компанії?
Використовуємо Docker, Docker Swarm, GitHub, Kubernetes, Scrutinizer, Helm, GoogleCloud, Figma, Sketch, Illustrator, PhotoShop, Android Studio, Xcode, PHPStorm, Grafana, Jenkins.
— На яких мовах програмування пишуть розробники?
Back-end в більшості написаний на PHP. Сильно навантажені мікросервіси — на Golang та інші поступово переводяться на цю мову.
Front-end: HTML5, CSS3, JS (ES8), деякі проекти на TypeScript. Поступово додаємо типізацію в інші проекти. Нативні мобільні додатки — Kotlin та Swift, напівгібридний — React Native, аналітичні системи — Python.
Також застосовуємо Node.js, SQL та Bash.
— Як виглядає процес розробки, життєвий цикл продукту?
Продуктологи вигадують нові фічі, після цього команда розробки вирішує, які з цих фіч реалізувати в поточному місяці. Перед початком реалізації можемо ще поговорити з продуктологами, запропонувати свої ідеї. Вони завжди хочуть зробити речі простими після реалізації. Фічу тестують на демоплатформі, після рев’ю коду деплоять на продукт, і там також відбувається тестування.
— Як прийнято проводити код рев’ю?
Перед проведенням код рев’ю пул-реквест з GitHub пропускається через CI сервер: на фронті це — ESLint, на PHP — Scrutinizer. Якщо все добре та всі тести виконуються, команда проводить рев’ю.
Зазвичай звертаємо увагу на стиль коду та логіку програми — це хороший обмін досвідом та відловлювання багів, а ще це покращує знання коду проекту. Головне, якщо щось не подобається — потрібно ставити «Request changes». Інакше на твої зауваження можуть і не звернути уваги.
— Як прийнято проводити тестування, які тести застосовуєте?
У нас є команда тестування, яка покриває проект інтеграційними, smoke- та іншими тестами. Самі ж розробники пишуть юніт-тести, адже все динамічно змінюється і без них тяжко контролювати, чи не зламається старе при додаванні нового. Також кожна фіча тестується мануально на тестовій та продуктовій площадці. Кожну п’ятницю команда тестувальників проводить регресійне тестування.
— Як відбувається розгортання (деплой)?
На систему розгортання було витрачено декілька місяців розробки. Це процес складний, але надійний. При пуші в репозиторій запускається автоматична збірка, яка збирає образи, оновлює кластер, запускає тести, code intelligent K8s, картинки в Docker Hub. Ingress перенаправляє трафік між подами, запускає джоби та вимикає старі поди.
Деплоїмо зазвичай до 14:00 з понеділка по четвер, щоб на вихідних та вночі не ловити баги.
— Як проходить типовий робочий день розробника вашої команди?
Приходити на роботу можна о будь-якій годині, але кожна команда має свій час мітингу, і на них ми не запізнюємось. Мітинги в нас стартують з 10:30, до цього часу ми дружньо снідаємо. Після мітингів приступаємо до виконання задач. Вільний від щоденних мітингів день — п’ятниця: тоді можна трохи розслабитись.
— Скільки годин на день працюєте?
Працюємо 8 годин. Але зазвичай в офісі проводимо більше 9 годин (оскільки час ще йде на сніданок, обід, «зробити паузу», «подрімати», навчальні мітапи). Буває і 10+ годин роботи, але до цього ніколи ніхто не примушує. Все залежить від власної мотивації та цікавості задачі.
— Що робить вашу компанію особливим місцем для розробників? Які є плюси і мінуси?
Команда розробки постійно слідкує за новими рішеннями та інтегрує їх. Проводимо щотижневі навчальні мітапи по категоріях Back-end, Front-end, DevOps — таким чином обмінюємось знаннями.
SimCorp
— Розкажіть про вашу команду і про те, над чим ви працюєте?
Наша команда є в якомусь сенсі унікальною в SimCorp UA: ми є частиною технічного департаменту, що займається розробкою ядра нашого продукту SimСorp Dimension та його ключових функціональних можливостей, які потім використовуються іншими командами для розробки бізнес-функціоналу. Це означає, що ми є першими, хто пропонує та запроваджує використання нових технологій у розробці продукту.
Наприклад, Cloud-розробка наразі є одним з найважливіших векторів розвитку продукту, що включає в себе адаптацію існуючого функціоналу та розробку величезної кількості нових веб-додатків.
Тож команда у Києві займається розробкою веб-продуктів та фреймворків, які у майбутньому будуть фундаментом подальшого розвитку SimCorp Dimension, відповідно до Cloud-стратегії компанії.
Зараз команда складається з 10 спеціалістів: 4 розробника, 2 DevOps-інженери, по одному manual QA, QA automation, Scrum Master та UX-дизайнер. Компанія має великі амбіції щодо Cloud розробки, і зараз ми суттєво розширюємо команду. Welcome.
— Які інструменти розробки використовують у вашій компанії?
Ми працюємо у SAFe (scaled agile framework), в компанії запроваджені методології Agile-розробки. Ми використовуємо V1 для трекінгу, Slack та продукти Microsoft для комунікації, а також Git та TFS, TeamCity, Microsoft Azure та багато інших. У нас завжди вітається ініціатива «try something new», тому ми багато експериментуємо з вибором нових інструментів.
— На яких мовах програмування пишуть розробники?
Більша частина існуючого десктопного продукту написана на мові APL, частина модулів — на C#. Для розробки нового веб-функціоналу використовуємо C#, TypeScript, JavaScript та такі фреймворки, як .NET Core 2.0, Angular 6.
— Як виглядає процес розробки, життєвий цикл продукту?
Весь процес розробки відповідає SAFe. Спочатку продакт-менеджери разом з командами готують фічі. Потім на PIPE (program increment planning event) кожна з команд бере фічі у роботу. Розробка проходить у тісній взаємодії з продакт-менеджментом. Цикл розробки — двотижневий спринт.
— Як прийнято проводити код рев’ю?
SimCorp є продуктовою компанією, відтак ми зацікавлені у високій якості коду, адже він з нами «назавжди». Використовуються практики Joint code review, парне програмування — це дозволяє залучити більше членів команди до процесу розробки та рев’ю.
— Як прийнято проводити тестування, які тести застосовуєте?
Для існуючого десктопного продукту переважно використовуємо внутрішні інструменти для створення автоматизованих тестів. Для тестування веб-функціоналу використовуємо тестування endpoint (XUnit), інтеграційне (Protractor, SpecFlow) та юніт-тестування.
Тестування, так само як і код рев’ю, інтегроване у процес розробки.
— Як відбувається розгортання (деплой)?
Середовище для тестування розгортається у Azure WebApps за допомогою пайплайну TeamCity. Наразі для production-деплою ми імплементуємо підхід Infrastructure As Code, з підготовкою Docker-контейнерів, що розгортаються у preproduction-кластері Kubernetes, а потім разом з усіма залежностями переходять до production-кластеру. Залежно від специфіки веб-продукту використовується Canary або Blue-Green тип розгортання.
— Скільки годин на день працюєте?
У компанії загальноприйнятий
Компанія лояльно ставиться до необхідності відлучитися у робочий час з особистих причин. Також, у разі потреби, є можливість працювати з дому.
— Хто у вашому випадку є замовником, як влаштована комунікація?
Для нашої команди замовником може виступати як інша команда, що потребує від нас певного функціоналу, так і клієнт, з яким, у цьому випадку, комунікує продакт-менеджмент.
Усі процеси, пов’язані з комунікаціями щодо розробки продукту, відбуваються безпосередньо через продакт-менеджмент. Продакт-менеджери також вирішують, якими є пріоритети розробки нового функціоналу.
— Що робить вашу компанію особливим місцем для розробників? Які є плюси і мінуси?
SimCorp — це стабільна продуктова компанія. Відтак, тобі не потрібно турбуватися, що рано чи пізно проект закінчиться і ти опинишся на бенчі або будеш змушений шукати новий проект чи місце роботи. Тут добре налагоджені усі процеси розробки та комунікацій. Компанія надає широкі можливості для професійного зростання, підтримує ініціативи щодо проходження тренінгів, сертифікацій, перекваліфікації співробітників, тощо.
Зараз ведеться активний рух в напрямку Cloud технологій. На жаль, процес розробки відбувається не так швидко, як нам би цього хотілося. Адже Simcorp Dimension є масштабним продуктом, що потребує зважених архітектурних рішень та узгоджень з усіма стейкхолдерами.
Splynx
— Розкажіть про вашу команду і про те, над чим ви працюєте?
Якщо коротко, то Splynx — це фреймворк для провайдерів. Програма призначена для білінгу, управління мережею і всім, що потрібно для роботи інтернет-провайдера, оператора мобільних мереж чи телебачення.
Сьогодні такі додатки, як Splynx — це ядро роботи провайдера, business-critical, як-то кажуть. У користувачів інтернету нульовий поріг лояльності, і якщо система має баги, то сервісний центр провайдера за лічені хвилини перетвориться в гарячий котел.
Splynx — це потужний набір модулів та відкриті інтерфейси додатків (API), тому ми називаємо це Framework. Для адміністраторів це означає практично необмежені можливості налаштування програмного забезпечення і відповідно стабільну роботу мережі.
Наразі Splynx підтримує роботу близько 300 провайдерів із різних країн, як економічно розвинених (США, Австралія, Англія, Іспанія, Канада), так і країн, що розвиваються (ПАР, Кенія, Непал, Албанія, Чилі, Колумбія, Мексика). Відповідно, у кожного провайдера своє законодавче поле (для прикладу, GDPR в ЄС), різні типи підключень в мережі (PPPoE, DHCP, IPoE, Hotspot, Wireless або Static IP/MAC), технічні можливості, обладнання, бухгалтерські та платіжні системи. Щоб забезпечити потреби кожного провайдера, ми розробляємо додаткові модулі для інтеграції.
Ми постійно працюємо над удосконаленням платформи. Нещодавно вийшов новий реліз 2.2, у якому додали ще більше корисних функцій. У подальшому плануємо додати власну CRM-систему та розробити мобільний додаток, щоб мережеві інженери мали доступ до Splynx в «полях».
У стартапі працює 11 розробників рівнем від Junior до Senior PHP.
— Які інструменти розробки використовують у вашій компанії?
Для внутрішнього спілкування — Mattermost. Для відслідковування завдань — Jira.
Для управління вихідним кодом використовуємо Git, як централізований сервер репозиторіїв — Bitbucket. Кожну задачу ми розробляємо в окремій гілці Git, що названа так само, як і завдання з Jira. Це дозволяє легко співвідносити зміни до вимог.
Коментарі в commit також мають номер завдання, щоб комміти відображалися в Jira Worklog. Виконані завдання переносяться (мержаться) в гілку development, а звідти — в момент релізу — в гілку master.
— На яких мовах програмування пишуть розробники?
Основна мова — PHP. Також є модулі, написані на JavaScript.
— Як виглядає процес розробки, життєвий цикл продукту?
Життєвий цикл проекту починається задовго до старту програмування. Після аналізу запитів наших клієнтів ми формуємо проектну групу. Про свої побажання клієнти пишуть на нашому форумі або роблять окремі запити в службу підтримки.
Проектна команда зазвичай складається з тімліда, розробників і тестувальників. Проектні рішення деталізуються на специфікації, заводяться завдання в Jira.
Управління розробкою проходить досить стандартний процес. Завдання призначається програмісту, який створює окрему гілку в репозиторії і починає з ним працювати. Після того, як завдання виконане, створюється пул-реквест. Розробник ще раз тестує свій функціонал і призначає декілька людей з команди для код рев’ю. Наступним кроком є узгодження завдання тімлідом, який приймає рішення по зливанню пул-реквеста в основні гілки.
— Як прийнято проводити код рев’ю?
Як я вже описав, після завершення роботи над задачею розробник створює пул-реквест, куди призначає
— Як прийнято проводити тестування, які тести застосовуєте?
Автоматичні тести у нас розробляють як програмісти (unit-тести), так і тестувальники (з використанням, наприклад, Codeception). У якості сервера інтеграції та безперервної збірки ми використовуємо Jenkins.
— Як відбувається розгортання (деплой)?
Створюються deb-пакети.
— Як проходить типовий робочий день розробника вашої команди?
Уранці — код рев’ю, потім свої робочі завдання в тиші та спокої, або не в тиші. Це вже залежить від музичних уподобань. Одним словом, програмістів ніхто не відволікає від творчого процесу, і вони не просиджують півдня на зустрічах та обговореннях.
— Скільки годин на день працюєте?
У нас стандартний
— Хто у вашому випадку є замовником, як влаштована комунікація?
Вся комунікація відбувається через пресейлів або сейлів. Саме вони обговорюють із кінцевим клієнтом (провайдером) можливості впровадження додаткового функціоналу чи встановлення продукту. Якщо ж справа стосується сервісу та підтримки вже існуючих клієнтів, то завдання вирішує власна служба підтримки через тікет-систему.
— Що робить вашу компанію особливим місцем для розробників? Які є плюси і мінуси?
Крім різних смаколиків, бонусів та соціальних пакетів Splynx — це цікавий, затребуваний продукт. Цікавий для тих, хто хоче розвиватися в сфері мережевих технологій та білінгу. Також плюсом є відсутність бюрократизму та надмірної процедурності. У нас добре налагоджена комунікація і здорова робоча атмосфера.
Недоліком є те, що для багатьох робота над одним продуктом виглядає досить монотонною, хоча це лише на перший погляд. Зважаючи на глобальність нашого бізнесу, широкий асортимент обладнання та вимог кожного із провайдерів, щоразу виникають різнопланові задачі та серйозні виклики для розробників.
Пишіть у коментарях, про які інші особливості роботи в компаніях ви б хотіли дізнатись у наступних випусках рубрики. Цікаві питання будемо додавати в анкету.
Якщо хочете взяти участь у наступних випусках рубрики, пишіть на valentina@dou.ua.