Архітектура, про яку зазвичай мовчать

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

Є інший аспект архітектури, про який майже ніхто не говорить. І він не пов’язаний безпосередньо з чистими залежностями або структурою проєкту. Він пов’язаний зі швидкістю. З тим, як саме архітектура впливає на продуктивність команди й визначає, як швидко система здатна розвиватися.

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

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

І саме про цю частину архітектури зазвичай не говорять.

Чому SOLID не рятує від втрати швидкості

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

Проблема не в тому, що код нечистий. Проблема в тому, що поведінка, яка має бути спільною, розмазана по різних частинах.

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

Справжній

Читати далі

#Meeting room з Software Engineer: Оптимізація legacy систем – практики та підходи

Сергій – наш успішний розробник, якому вдалося попрацювати на проєктах з безліччю викликів. Сьогодні ми поспілкувалися з ним про те, як підійти до роботи з legacy-проєктом, подолати технічні виклики та покращити performance системи.

Розкажи, який проєкт запам’ятався тобі найбільше, так би мовити загартував тебе? 🙂

– Це був проєкт для нашого великого замовника із США у бізнес домені FinTech, що працює з оподаткуванням для компаній у різних куточках світу. Саме там я вперше зустрівся із legacy системою.

Які перші виклики здавалися тобі найбільш серйозними?

– Коли я починав працювати над legacy проєктом, найбільшим викликом була відсутність чіткої документації та розуміння архітектури.

Читати далі

Що таке RAG і в чому з ним проблема

what_is_rag

RAG (Retrieval-Augmented Generation) — це сучасна архітектура, яка дозволяє генеративним моделям (на кшталт ChatGPT/LLM) користуватися вашою локальною базою знань. Інакше кажучи, ви можете завантажити свої документи і спілкуватися з ChatGPT, яка володітиме всіма наданими їй знаннями.

RAG поєднує дві складові: генеративну модель (LLM), яка “вміє красиво говорити”, і зовнішню базу знань, яка “знає, де що лежить”. Ідея проста: коли модель не має потрібної інформації, вона спершу робить запит до бази, знаходить релевантні фрагменти тексту (retrieval), а потім формує відповідь на їхній основі (generation).

Виглядає перспективно й корисно. Але в чому ж тоді проблема?

Сучасні RAG нагадують людину з поганою пам’яттю, яка шукає способи компенсувати свою ваду. Вона починає впорядковувати знання: все записує, все класифікує. Ось у цій шухляді — інформація про ліки, які я приймаю, у тій — комунальні платежі, а десь там — переписка з друзями. Але ця організація не вирішує головної проблеми. Бо незрозуміло, яка саме інформація взагалі є. Через недосконалу структуру даних людина може шукати відповідь не в тій шухляді — або просто не помітити потрібне.

Переходимо від метафори до технічної реальності:

1. Модель не “пам’ятає”, а лише “запитує”

LLM у RAG не має справжньої пам’яті: кожен запит обробляється незалежно від попередніх. У моделі немає відчуття контексту розмови, історії користувача чи стратегічної мети. Вона нічого не згадує — лише витягує уривки з індексу.

2. Пошук працює як сліпа інтуїція

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

Читати далі

Як ми розв’язали задачу, яка не мала технічного рішення

interlink_case_study

Ми в ІнтерЛінк створювали систему бронювання сервісів із можливістю миттєвої купівлі. На перший погляд, задача здавалася типовою. Проте з перших же спроб стало очевидно: стандартний підхід не спрацює.

Чому так складно просто «забронювати»

Щоб підтвердити замовлення, потрібно виконати послідовно декілька кроків:

  • перевірити, чи доступний сервіс на обране клієнтом вікно часу (3 секунди),
  • забронювати його у провайдера (5 секунд),
  • провести оплату на наш рахунок (5–10 секунд),
  • підтвердити бронювання у провайдера (ще 5 секунд).

У найкращому випадку — 18 секунд. У реальному світі — ближче до 25.

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

Коли проблема не в швидкості, а в тиші

На етапі брейнштормів команда зробила важливе спостереження: користувачі рідко обурюються самою тривалістю процесу. Проблема — у відсутності зворотного зв’язку. Якщо система просто показує повідомлення типу “Booking is in progress…” і нічого більше не відбувається — користувач втрачає довіру. А отже — і покупку.

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

Прозорість як інструмент довіри

Ми змінили інтерфейс і розбили процес на чіткі етапи з миттєвою зворотною реакцією:

  • Перевіряємо доступність часу — Ура, час доступний.
  • Бронюємо сервіс — Супер, бронь підтверджено.
  • Проводимо оплату — Чудово, гроші отримано.
  • Оформлюємо підтвердження — Готово, усе працює.

У підсумку той самий технічно складний і довгий процес перетворився на спокійний, зрозумілий і приємний досвід для користувача. Ніхто не скасовував купівлю. Ніхто не жалівся. А ми — не ризикували нічим.

Що варто винести з цього кейсу

Користувачі не проти чекати — якщо

Читати далі

#Meeting room з Software Engineer: 10 років на проєкті – нудно чи захоплююче?

Коли проєкт – як ціле життя, в якому було і зростання, і стратегічні зміни. Ми раді, що є проєкти, які з нами вже багато років. Не менш цінуємо людей, що вже стільки років поспіль невтомно допомагають зростати таким проєктам. Сьогодні ми спілкуємося з такою людиною – нашим Software Engineer Олександром, який провів на ентерпрайз проєкті більшу частину своєї кар’єри. Приємного читання!

Розкажи як ти потрапив на роботу програмістом в ІнтерЛінк?

Після завершення університету я почав пошук роботи. Переглядаючи вакансії, я вирішив тримати фокус орієнтовано на Java, оскільки я вивчав це на одному з останніх курсів, та, порівняно з іншими високрівневими мовами, Java була мені найкомфортніша. Навіть не пам’ятаю як саме, але серед перших знайдених мною пропозицій була вакансія для початківців від ІнтерЛінк.

Це була моя перша співбесіда, тому я нервував, та мабуть трохи наївно сподівався, що підготовки за конспектами та матеріалами, що залишилися з універу, буде достатньо. Що ж, це був провал :). Але щось-таки я зміг продемонструвати достатньо, щоб отримати рекомендації як підвищити рівень своїх знань, і вже пізніше спробувати знову. Так і йшов надалі мій час за сторінками Thinking in Java.

Одного дня, ще навіть не набравшись впевненості в своїх силах, я несподівано отримав

Читати далі

#Meeting room: спілкуємось із Senior Software Engineer

Доброго зимового ранку, шановні читачі нашого блогу. Сьогодні у нашій #meeting room ми говоримо з нашим Senior Software Engineer Володимиром. Чи дійсно написання коду – це основна робота програміста та що найголовніше у командній роботі? Приємного читання!

Яке твоє найбільше усвідомлення за роки у сфері розробки?

Всі ми вміємо гарно виконувати свою роботу, наприклад – писати код або тестувати функціонал. Але не менш важливим є створення комфортної обстановки у команді та у спілкуванні із замовником. Саме взаєморозуміння у команді дозволяє створювати чудові продукти та ділитися навичками у команді.

Продолжить чтение

Читати далі

#Meeting room: спілкуємось із QA Lead

Ми продовжуємо знайомити вас із нашою командою. І сьогодні ділимося роздумами нашого QA Lead Романа про напрямок тестування та розвиток у цій професії. Приємного читання! 

Як ти прийшов у професію? Відразу хотів цього чи розуміння прийшло з часом?

Так вийшло, що я нічого не знав про тестування і починав працювати в першій IT-компанії як Technical Writer.
Згодом задач по розробці документації було не так багато, а у відділі тестування було багато задач та мені запропонували спробувати допомогти. Так я втягнувся і повністю став тестувальником.

Як зрозуміти, що тестування – це твоє? Які плюси та мінуси цієї професії?

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

Читати далі

#Meeting room: спілкуємось із Project Manager

Професія РМ – багатогранна та захоплююча. Як врахувати інтереси всіх сторін, переключатися між різними задачами та проєктами, управляти своїм часом та при цьому не втрачати натхнення та знаходити час для власних проєктів? Сьогодні ми запитали у нашої енергійної Олени Кондратової.  

Чим тебе зацікавила професія РМ?

У школі мене називали завгоспом. Коли була можливість взяти на себе відповідальність – я завжди брала і намагалася довести поставлену задачу до кінця. Через 10 років виявила, що професія менеджера – це саме про це. Я вступила на факультет математики і інформатики, де майже усі кодили і були програмерами. Але я відчувала, що мені більше подобається комунікація, планування і структуризація. Випадково я дізналася, що програмерами має хтось керувати або слідкувати за процесом, іншими словами. Зрозуміла, що це якраз для мене, так я стала PMом :).

Що найбільше тобі подобається у роботі

Читати далі

#Meeting room: спілкуємось із Software Engineer

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

Розкажи про свій шлях в компанії

Напевно почну із порівняння себе зі сліпим кошенятком, яке потрапило на інтернатуру, маючи невеликий досвід декількох лабораторок з універу. Тут я познайомився з чудовим ментором Олександром Котовим, який став для мене та інших інтернів як “котяча мама”, котра підштовхує свою дитину в правильному напрямку. Після закінчення інтернатури, для мене відкрився величезний світ IT. До цього моменту я встиг побувати на дуже різноманітних проектах. Одні були великі, з великою командою, інші маленькі, навіть доводилось працювати самому. Всі ці проєкти обʼєднувала одна невідʼємна річ – це класні люди. Тімліди, техліди, QA, менеджери, та навіть замовники – всі вони зробили значний внесок у формування мене як професіонала, за що я безмежно вдячний кожному. Зараз же команда вже формується навколо мене, і я стараюсь передавати той досвід, якого

Читати далі

#Meeting room: спілкуємось з РМ – Написання ефективного Escalation Email

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

Дотримуйтесь дружнього тону

Ввічлива та дружня комунікація є важливою у складних ситуаціях. Пам’ятайте, що ефективна комунікація сприяє співпраці та розумінню. Ставтеся до зацікавлених сторін так як очікуєте, щоб ставилися до вас.

Поясніть проблему

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

Читати далі