Апр. 07

Куди переходити з Java. Розвиток кар’єри Java-розробника

Стаття написана у співавторстві з Ярославом Клочником та Андрієм Забавським.

Привіт, я Юлія Матушкевич, Talent Success Lead (TSL) у львівському розробницькому центрі SoftServe, працюю з Java-компетенцією. Моя роль — це балансування між потребою бізнесу й талантами. Тобто, окрім того, що я добре орієнтуюся в активностях, які відбуваються в компанії за напрямом Java та на ринку, я постійно перебуваю в контакті з інженерами та їхніми менеджерами. Розуміючи особисті інтереси працівників та знаючи контекст компанії (які проєкти заходять та з якими технологіями, які нові напрями з’являються тощо), я допомагаю інженерам знаходити можливості для професійного зростання у межах компанії. Зокрема, координую процес переходу між проєктами та зміну компетенції, працюю з фахівцями, які в резерві.

Java-інженери різних рівнів часто цікавляться можливостями здобути новий досвід, який не потребує кардинальної зміни компетенції, а базується на знаннях, які вони отримали, працюючи з Java. Тому ми разом з технічними експертами вирішили підготувати короткий гід на цю тему.

Згідно з останнім дослідженням DOU, Java є однією з найпоширеніших мов програмування в Україні. В SoftServe простежується така сама тенденція. Java відкриває широкі можливості для професійного розвитку, оскільки дає змогу отримати цінний досвід: робота з різноманітними фреймворками, типами баз даних, унікальною архітектурою, високонавантаженими системами, кооперація із замовниками та співпраця з особливими доменами бізнесу клієнтів.

Проте якщо сфера ваших зацікавлень уже ширша за безпосередньо Java і пов’язана з архітектурними рішеннями, типом взаємодії з клієнтом, використанням Big Data, AI/ML чи платформами, і для цього є бажання опанувати нову технологію чи перейти в інший напрям, то чому ні?

Далі ми розкажемо про найбільш популярні, за нашим спостереженням, напрями розвитку з Java зараз.

Платформи

Може здатися, що робота з платформами — це просто, оскільки треба лише взяти готові елементи, які вони пропонують, і адаптувати під потреби конкретного проєкту. Насправді це складна інженерна робота, яка складається з:

роботи з платформою — її конфігураціями, побудовою інтеграцій тощо;
розробки додаткових елементів — частину з них потрібно писати з нуля під конкретний проєкт;
тісної співпраці з бізнесом.

Загалом платформи стрімко розвиваються, надають усе ширший функціонал, для компаній це цікаво. Ми бачимо значний попит від клієнтів, водночас ринок талантів не заповнений (відповідно конкуренція менша).

Розглянемо дві категорії платформ.

iPaaS (інтеграційні платформи — Mulesoft, Apigee, Dell Boomi)

Як зазначає Вікіпедія, System Integration (або Data Integration) — це маршрутизація даних з розрізнених джерел (баз даних, систем, мобільних/вебзастосунків через API тощо) в єдину систему/платформу в межах організації або організацій. Мій колега Ярослав Клочник написав докладну статтю про інтеграційні платформи, тож переказувати його не буду.

Якщо коротко, то інтеграційні платформи допомагають, коли:

Клієнт застосовує підхід вертикального масштабування (vertical scaling) і приходить до нас із запитом інтегрувати систему, яку він уже використовує з новою (наприклад, Workday з SAP SuccessFactors).
Клієнт застосовує підхід горизонтального масштабування (horizontal scaling) і розвиває власну систему та додає до неї нові модулі. І потрібно швидко об’єднати ці модулі для роботи з даними, трансформацій, синхронізації даних тощо.

Безумовно, застосування інтеграційної платформи не єдиний варіант. Можна ще обрати USP-рішення, наприклад Apache Kafka. Але, будьмо відвертими, конфігурування цієї платформи — ще та задачка навіть для дуже досвідчених інженерів. З інтеграційною платформою це робиться набагато швидше й простіше.

Тобто, простими словами, кожна інтеграційна платформа — це набір блоків, з яких ви будуєте те, що вам потрібно. Водночас вона надає ще критично важливі додаткові сервіси (частково покриває USP, безпеку, формує data layer).

Як перейти в цей напрям

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

З основного, що потрібно вивчити:

об’єктноорієнтовану мову програмування;
специфіку самої інтеграційної платформи (у нас інженери починають зі знання однієї платформи, але на етапі промо до техліда і вище потрібно вміти працювати мінімально із двома платформами);
вебсервіси REST/SOAP;
інтеграційні патерни;
формат обміну даними.

На наступних етапах потрібно буде розуміти також:

скриптову мову (JavaScript або Groovy);
принципи безпеки;
дизайн баз даних;
роботу з хмарами.

Які сертифікації здавати:

Dell Boomi Associate Developer Certification
Professional Developer Certification
MuleSoft Certified Developer

Наступний крок — це більш просунуте навчання, сфокусоване на специфіці проєкту, котре поєднує продуктову та технічну частини та займає до місяця часу.

Тобто за два місяці розробник уже готовий до роботи над реальним інтеграційним проєктом під наставництвом більш досвідченого фахівця.

Наприклад, за словами мого колеги Миколи Мацяха, Middle System Integration Engineer, він починав з мобільної розробки під Android на Java у продуктовій компанії. Вперше почув про інтеграційні платформи на співбесіді у SoftServe. Його зацікавило те, що тут поєднується написання коду з адаптацією готових компонентів системи. На початку роботи в команді він кілька тижнів навчався та готувався до сертифікацій. Тоді здавав Dell Boomi Associate Developer і Dell Boomi Professional Developer, пізніше — ще Dell Boomi Professional Architect. Після цього його одразу взяли на клієнтський проєкт на позицію Junior, за два роки він отримав підвищення до Middle.

Salesforce

Хмарна CRM-система для управління бізнес-процесами в галузі продажів, обслуговування клієнтів, цифрового маркетингу. Вона складається з кількох окремих продуктів, зокрема Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, Financial Services Cloud, Health Cloud.

У 2007 році Salesforce запустила Force.com — першу PaaS-платформу для розробки та розгортання застосунків в інфраструктурі Salesforce. 2018 року її перейменували у Lightning Platform.

Якщо говорити про роботу на цій платформі, то тут є дві ролі:

консультанти — вивчають потреби клієнта і продумують, як Salesforce може їх задовольнити;
технічні експерти (інженери, архітектори).

Особливість Salesforce в тому, що навіть технічні експерти тут є client facing. До цього повинні бути готові ті, хто вирішить спробувати себе в цьому напрямі. Це вимагає відповідних комунікаційних навичок, самого лише знання технології мало.

На це є причина. Усі платформи впливають на бізнес своїх користувачів, але Salesforce відрізняється тим, що безпосередньо налаштовує процес продажів і багато супровідних процесів. Тобто безпосередньо впливає на прибуток. Її функціонал використовують COO, CMO та інші бізнес-стейкхолдери. Тому з ними потрібно бути весь час на зв’язку, щоб знати потреби, отримувати фідбек і оперативно реагувати. Понад те, треба розуміти бізнес і говорити його мовою.

І загалом темп роботи дуже динамічний. Можу виділити ще одну особливість — Salesforce написана на Apex (Java-подібна мова, на якій реалізовується складна бізнес-логіка), всю рутинну роботу бере на себе платформа. Тому потрібні thinkers, а не doers, які готові вчитися, шукати шляхи подолання викликів та швидко адаптуватися.

Для реалізації роботи інтерфейсу використовують сучасний JS Framework — Lightning Web Components, який відповідає стандартам es6.

Як перейти в цей напрям

Є курс, розроблений Salesforce — Trailhead. Там багато інформації. Наприклад, оверв’ю самої платформи — у цьому розділі. Загалом курс довгий. Відверто кажучи, в ньому є багато води, але й корисного теж. Особливу увагу раджу приділити частині про безпеку.

Якщо знати основи Java і пройти урок за уроком, можна претендувати на позицію Junior. А якщо маєте вже 2–3 роки практичного досвіду розробником — вийти навіть на Middle.

Які сертифікації здавати? Platform Developer 1 для початкового рівня, для наступних рівнів — відповідні номери цієї ж сертифікації.

Кейси переходу в Salesforce трапляються як серед досвідчених розробників (для таких у нас є retrain course, де за два місяці людина достатньо ознайомлюється з платформою, щоб отримати першу сертифікацію та претендувати на посаду Middle Salesforce Developer), так і новеньких. Наприклад, одна з розробниць прийшла в команду Salesforce одразу після закінчення SoftServe IT Academy за напрямом Java. Коли практичний досвід мінімальний, на навчання йде більше часу. Тому перші пів року роботи вона присвятила суто вивченню платформи та проходженню курсу Trailhead. Далі отримала Platform Developer 1, після чого її почали залучати на клієнтські проєкти. Тепер, рік після того, вона готується до наступної сертифікації, щоб перейти на рівень Middle.

Big Data

Інженерія великих даних стала актуальною ще 10 років тому. Що відбувається в цій сфері сьогодні? Якщо коротко, вона набирає все більших обертів. Постійно з’являються нові джерела даних, ринок стрімко зростає. За прогнозами Fortunebusinessinsights, до 2027 року його обсяг зросте до 116 млрд доларів. Багато організацій прагне бути data-driven, тобто ухвалювати зважені рішення на основі реальних даних та аналітики.

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

Тож збільшується і потреба в експертах. За даними QuantHub, інженер з роботи із великими даними — це профайл, який зростає найшвидше серед усіх IT-спеціальностей. На локальному ринку простежується така ж тенденція.

Напрями Data Engineering

У роботі з великими даними є чотири ключові етапи. Думки розходяться щодо того, чи повинен це все робити один інженер, чи під кожен процес має бути вузькоспеціалізований фахівець. У будь-якому разі усе це — в межах однієї експертизи, тому потрібно розуміти кожен з наведених нижче процесів.

Вибір рушія баз даних (Database engine). Якщо раніше реляційна модель була де-факто стандартом і вибір коливався довкола різних реляційних СКБД, то нині є тисячі варіантів.

Вибір правильного з них — складний компроміс, що базується на багатьох аспектах, таких як властивості масштабованості, транзакційності, гнучкість моделі, шаблонів доступу до даних (операційні точкові запити чи аналітичні великі сканування), властивості доступності, відмовостійкості, підтримка відповідних рівнів ізоляції та узгодженості, графових і геолокаційних структур, повнотекстового пошуку, можливості фільтрації за неключовими атрибутами, доступність операцій групування та об’єднання сутностей, мови запитів на кшталт SQL, можливості рідного розгортання на хмарі, поширеність на ринку, зрілість, підтримка спільноти, ціна використання та ще багато іншого.

Моделювання даних. Проєкція реальних сутностей і процесів на вибраний рушій баз даних — це часто нетривіальне завдання. Тут можна розділити світ на дві частини — реляційний та нереляційний.

Переваги моделювання в реляційному світі — наявність добре пропрацьованих методологій та безлічі шаблонів для наслідування. Однак є багато компромісів: намагатися застосувати підхід високонормалізованих структур, щоб уникнути дублювання та проблем з аномальними оновленнями, чи створювати де-нормалізовані структури, щоб уникнути операцій об’єднання відношень. Перший підхід дасть змогу максимально якісно реалізувати модель для операційної діяльності, водночас другий є кращим для аналітики, тобто запитів, що сканують великі обсяги даних.

Своєю чергою, високонормалізовані структури мають різні варіації та ступені нормалізації, а також і цілі методологічні напрями, як-от склепіння даних (Data Vault), якірна модель (Anchor Modelling) та інші.

У сфері аналітичних моделей є своя методологія з добре напрацьованими підходами багатовимірного моделювання на основі зіркоподібних структур.

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

Побудова інтеграційних процесів. Це найбільш трудомісткий процес, який може займати до 70 відсотків усіх зусиль побудови аналітичного проєкту.

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

Однак не варто забувати і про функціональну частину. З точки зору обробки даних важливим є забезпечення належної якості даних, відповідності до стандартів відкритості чи захищеності, можливості відстежувати походження даних (data lineage) та низка інших вимог.

Якщо говорити про виклики інтеграції, то їх безліч. Тут можемо зауважити про інкрементальний видобуток даних з джерел через різні інтерфейси доступу, очищення, дедублікацію, узгодження даних, збагачення даних через сторонні словники даних, збереження аудиту всіх операцій, а також організацію оркестрації усіх процесів з відповідною почерговістю та взаємозалежністю.

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

Є також неочевидний на перший погляд компроміс між контролем якості даних і швидкістю їх доставлення до адресата: що швидше ми доставляємо дані, то менше часу залишається на якісну перевірку та збагачення даних. Тому добре розуміння інструментарію, що надають технології, та правильне його застосування в умовах швидкої паралельної заливки даних є часто визначальною рисою експерта.

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

Тут важливо, окрім почуття прекрасного та навичок в ефективній подачі даних для користувачів, бажання заглибитися в бізнес-процеси, аби зуміти перетворити дані в реальні рекомендації для оптимізації операційної діяльності та підвищення прибутку.

З чого почати

Один з варіантів, як заглибитися у світ великих даних — вивчати сервіси та підходи одного з хмарних провайдерів. Якщо є окреслений потенційний проєкт на конкретному хмарному провайдері (GCP, Azure, AWS), то варто почати зі спеціалізованих онлайн-курсів, які пропонує кожен з них. Курси підготовки до хмарних сертифікацій зазвичай подають матеріал чітко і структуровано, що допоможе добре освоїти теорію та трохи попрактикуватися на лабораторних роботах.

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

Доволі репрезентативними тренінгами в цій сфері можуть бути зі Spark (приклад системи, що підтримує паралельні обчислення) та Cassandra (приклад NoSQL розподіленої бази даних).

Деякі хороші ресурси:

Книга Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable SystemsPaperback.
YouTube-курс з розподілених систем.
DataStax Academy з вивчення Cassandra.

Досвід переходу мав наш колега Аделін Ганаєм з розробницького центру SoftServe в Болгарії. Він починав свій шлях в ІТ з позиції Java бекенд-розробника. Попрацювавши на кількох проєктах, він дійшов висновку, що для нього тут забагато рутини та однотипних завдань. Але якось йому трапився проєкт для телекомунікаційної компанії, де були якраз задачі, пов’язані з даними. У клієнта була велика кількість користувачів, які генерували мільйони call data records (CDRs), що зберігалися в одному великому SQL-сервері. Через це процес генерації рахунків займав занадто багато часу. Вертикальне масштабування в такій ситуації невигідне, та і загалом його зробити майже неможливо. Стало зрозуміло, що тут виходом буде використати Hadoop і MapReduce.

Так Аделін отримав перший досвід роботи з цими технологіями. Це було близько 10 років тому, саме коли Hadoop був новинкою і загалом Big Data ставала трендом. Уже тоді було зрозуміло, що за цими технологіями майбутнє.

Сам перехід з Java у Big Data колега почав 6 років тому, маючи за плечима два проєкти, пов’язані з великими даними. Він почав з поглибленого вивчення Hadoop і MapReduce. Повністю заглибився у напрям Big Data, коли перейшов у SoftServe в Big Data Center of Excellence.

Висновок

Загалом перехід з однієї компетенції в іншу — хоч непростий, інколи довготривалий, проте абсолютно реальний крок. Головне — зрозуміти, куди є бажання розвиватися. Можливо, варто спробувати зробити власний маленький проєкт на обраній технології або пройти практичний тренінг. Попрацювати із ментором або ж ознайомитися із теоретичною складовою цікавої для вас мови програмування з доступних відкритих джерел. Звісно, зміна напряму потребує значних зусиль, адже треба буде вивчити багато нового, проте це також відкриє можливості для професійного зростання.