Коли проєкт – як ціле життя, в якому було і зростання, і стратегічні зміни. Ми раді, що є проєкти, які з нами вже багато років. Не менш цінуємо людей, що вже стільки років поспіль невтомно допомагають зростати таким проєктам. Сьогодні ми спілкуємося з такою людиною – нашим Software Engineer Олександром, який провів на ентерпрайз проєкті більшу частину своєї кар’єри. Приємного читання!
Розкажи як ти потрапив на роботу програмістом в ІнтерЛінк?
Після завершення університету я почав пошук роботи. Переглядаючи вакансії, я вирішив тримати фокус орієнтовано на Java, оскільки я вивчав це на одному з останніх курсів, та, порівняно з іншими високрівневими мовами, Java була мені найкомфортніша. Навіть не пам’ятаю як саме, але серед перших знайдених мною пропозицій була вакансія для початківців від ІнтерЛінк.
Це була моя перша співбесіда, тому я нервував, та мабуть трохи наївно сподівався, що підготовки за конспектами та матеріалами, що залишилися з універу, буде достатньо. Що ж, це був провал :). Але щось-таки я зміг продемонструвати достатньо, щоб отримати рекомендації як підвищити рівень своїх знань, і вже пізніше спробувати знову. Так і йшов надалі мій час за сторінками Thinking in Java.
Одного дня, ще навіть не набравшись впевненості в своїх силах, я несподівано отримав запрошення на курси, організовані ІнтерЛінком, по проходженні яких я міг отримати позицію джуніора у компанії. На ті часи це був нечуваний шанс. Так я і зустрівся з деякими своїми майбутніми колегами.
Розкажи про проєкт, над яким ти працюєш останні 10 років?
Це проєкт тривалістю приблизно 14 років, і він зі мною більший час моєї кар’єри. Замовник – транснаціональна корпорація, що працює у галузі комунікаційних та мережевих технологій. За довгий час його існування я встиг побачити масивні зміни та еволюцію цього проєкту.
Продукт, що ми розробляємо, з часом став самостійним інструментом для вирішення задач з інтеграцією та звітністю для великого об’єму даних, що циркулюють у компанії-замовника. Тож він все більше і більше потребував винаходити досить специфічні рішення нових задач.
Сам проєкт на цей час складається з декількох модулів, які доповнюють одне одного. Оскільки наш клієнт – дуже велика компанія – об’єм даних, що генерують ії бізнес процеси – теж досить великий. Зараз для об’єднання та обробки таких масивів ми використовуємо Databricks. Саме тут нам вдалося організувати комплексну систему для використання можливостей платформи, а також імплементації специфічних для бізнес процесів правил обробки терабайтів даних. За допомогою розробленого нами Java фреймворку, що займається генерацією коду, ми зробили систему інтуїтивною та гнучкою для швидкої розробки та внесення змін в процеси обробки даних.
Також для зручності користування даними та організацією їх у звіти ми створили веб-додаток на Java та React. Він дозволяє користувачам гнучко створювати звіти, використовуючи графічний інтерфейс, без потреби в технічних знаннях скриптування чимось на кшталт SQL.
Які технології переважають на проєкті? Чим був обумовлений їх вибір?
За роки проєкт пережив кілька суттєвих змін технологічного стеку. В основі веб частини завжди були Java + Spring Framework, зі зростанням проєкту ми лише підтягували версії. А ось клієнтська частина пережила кілька “стрибків”, починаючи з простого JS + jQuery через AngularJS – і тепер вже на React. AngularJS, на жаль, переживав концептуальні трансформації відразу після того, як був доданий у проєкт. Та коли постав вибір чи переходити на новий Angular чи інший фреймворк, наш вибір зупинився на React.
Бази даних, що використовувались для проекту, теж встигли змінитися. Починаючи від міграції з Oracle до Oracle Exadata, коли об’єми даних в системі почали зростати. А потім і на MS SQL, Analytics, та Databricks, коли замовник прийняв стратегічне рішення перенести проект у Azure Cloud.
Які були найбільші виклики, з якими ти стикався під час роботи?
Одним з найбільших викликів був перехід проєкту на Oracle Exadata. В цей час потрібно було перенести велику частину обробки даних на нову платформу, де використання старих підходів вже не змогло справитися з передбаченим збільшенням об’єму даних.
Так і виник новий фреймворк. Найбільшим розчаруванням стало, коли перша його версія виявилася нежиттєздатною. І це в саме той час, коли інші розробники вже перебудували цей фреймворк для розробки на ньому. Наступна версія вже використовувала інший підхід, і нарешті працювала як потрібно. Все ж деяке розчарування в надіях, покладених на першу версію, в мене залишилось. Але те, що було засвоєно в цей час, допомогло при наступній міграції на Databricks.
Наскільки часто доводиться розбиратися з новими технологіями чи бібліотеками і підтягувати знання в команді? Як це відбувається у вас?
Робота з ентерпрайз проєктами зазвичай характеризується використанням стабільних версій бібліотек та дуже рідким оновленням технологій. Це пов’язано з мінімізацією ризиків регресії проекту, тобто виникнення помилок у вже існуючому функціоналі. Тому введення нових технологій зазвичай нав’язується обставинами, такими як:
- неможливість системи більше підтримувати нові фічі, тому що вона обтяжена можливостями застарілих технологій;
- виявлення вразливостей в застарілих залежностях;
- “роздуття” кількості коду, необхідного для підтримки певного функціоналу. При тому, що використання чогось новішого спростило би розробку, допомогло і додаванню нових фіч і підтримки існуючих.
Коли в проєкт планується додавання нових технологій, або навіть якщо наразі таких планів немає, але ми знаходимо цікаву технологію – ми організовуємо командне навчання. Після пошуків необхідних матеріалів, які нам сподобались, ми кожного тижня беремо деякий обсяг на ознайомлення. Кожен з команди готує кілька питань в форматі тесту. В обраний день ми організовуємо міт для обговорення того, що ми прочитали, та проходимо тест по всіх об’єднаних питаннях. Після того, як ми бачимо оцінки та типові помилки у відповідях – аналізуємо що було некоректно сприйнято з навчального матеріалу.
Чули, що ти був одним з розробників власного фреймворку, розкажи як ця ідея втілилась в життя і який ви отримали результат?
Основна ідея фреймворку була – пришвидшити та автоматизувати розробку процесів обробки даних. Нам потрібно створювати таблиці, що заповнюються даними з великої кількості інших таблиць. На момент створення тодішньої версії фреймворку, ми використовували Oracle Exadata. Звісно, можна було писати кілометри SQL скриптів для вирішення подібної задачі, але ніхто не зміг би розібратися в такому коді, коли потрібно вносити зміни. Тож для вирішення цієї проблеми використали генерацію коду. Фреймворк був написаний на Java та використовувався для об’явлення Java класів-конфігурацій, в кожному з яких переписувалися конкретні правила заповнення з спрощеним інтуїтивно зрозумілим форматом.
Комбінуючи конфігураційні класи, розробники мають можливість будувати комплексні рішення, які набагато легше читати та модифікувати. Далі “двигун” фреймворку займався генерацією SQL скриптів, що і виконувались на базі даних.
Звісно ціною такого підходу була втрата деякої гнучкості, яка доступна в чистому SQL. Але типовість та шаблонність рішень, написаних з використанням фреймворку, дозволяла рішенню існувати в довгостроковій перспективі, а для цього потрібна мінімізація зусиль розробників для розуміння того, що саме відбувається у написаному коді, коли у вас сотні елементів конфігурації.
Перша версія фреймворку вийшла невдалою, так як підхід в середині фреймворку, а саме SQL скрипти, були задизайнені невдало і не справлялися з об’ємом даних. Наступна версія вирішила цю проблему. Фреймворк виконував свою роль ще багато років, аж поки не знадобилась зовсім нова версія вже для платформи Databricks.
То 10 років на проєкті – це нудно чи захоплююче?
Тут значну роль грає характер проєкту. Проєкт активно розвивався всі ці роки, кожна зміна та додана фіча мала достатньо індивідуальний характер, щоб не стало нудно від рутинної роботи.
Також кілька великих стрибків з введенням нових технологій було поштовхом проєкту. Це теж зовсім не рутинні процеси, які навіть спершу сприймались трохи грізними, після того як звикаєш довгий час до роботи у знайомому технологічному стекові. Так що нудьгувати не доводиться!
Чим тобі подобається займатися у вільний час?
Я полюбляю компьютерні ігри. Мабуть жодна інша індустрія розваг не пропонує настільки різноманітний вибір. Найулюбленіший жанр – RPG.
Також полюбляю науково-фантастичні, фентезі, екшен фільми.
Як ментор, що допомагає джуніорам, які поради ти б дав іншим менторам-початківцям?
Джуніори схильні забігати у “глухий кут” та бояться просити допомоги, витрачаючи значний час щоб вирішити проблему самостійно. На жаль, це лише призводить до негативних результатів – час втрачено, проблема не вирішена. Перевіряйте періодично чи не виникло такої ситуації. Щоб підняти рівень ознайомлення джуніора з кодом, можна залучати його до код-ревью. Так людина побачить як типові рішення примінені на проекті більш досвідченими розробниками.
Також я помічав схильність погоджуватися в усьому з більш досвідченими розробниками, коли наприклад сіньйор демонструє свої зміни у проект. Джуніори бояться задавати питання. В такий час потрібно донести, що командна робота передбачає не просто розділення на задачі. Чим раніше комунікаційний бар’єр буде подолано – тим краще. В якості літератури на подібну тему найчастіше рекомендують “П’ять вад команди” Патріка Ленсіоні. Крім того, завжди можна простимулювати комунікації, спитавши особисту думку джуніора, навіть коли відповідь вам вже відома.
Підсумовуючи сказане, окрім практичних навичок, працюйте і над роботою у команді.
Яку найважливішу річ про роботу програмістом ти зрозумів для себе за ці роки у розробці?
Репутація перед клієнтом набувається не лише шляхом якісно зробленої роботи, а і тим як, відбувається комунікація. Проблеми виникатимуть завжди, це специфіка нашої галузі, деякі з них будуть такими, що потребуватимуть не просто внесення декількох змін у коді. Проблеми, які роблять неможливим досягнення запланованих дедлайнів, або навіть перегляду вже існуючого дизайну. Але те, як ви донесете причини та можливі шляхи вирішення, може вплинути на сприйняття професійного рівня команди розробки в цілому. Комунікаційні та організаційні навички – це те, чого потребує наша робота.
You are not signed in. Sign in to post comments.