Коли люди роблять ремонт, вони майже завжди думають про велике: стіни, вікна, підлогу, меблі. А потім настає грудень, з’являється ялинка, гірлянда — і раптом з’ясовується, що розетки «тут не планувалися». Починаються подовжувачі, трійники, дроти через усю кімнату і універсальне виправдання: «Ну, потім якось вирішимо». Вирішити можна. Але дорого, негарно і незручно.

З програмною архітектурою відбувається рівно те саме.

На старті проєкту команда зазвичай зосереджується на ключовому функціоналі: основні модулі, бази даних, API, інтеграції. Усе виглядає логічно й охайно. Але якщо на цьому етапі не закласти важливі «дрібниці» — розширюваність, майбутні сценарії, точки зростання, — згодом вони починають з’являтися хаотично. Функціональність нарощується, архітектурні рішення ухвалюються несистемно, під тиском дедлайнів або конкретного запиту. У результаті те, що мало бути однією продуманою частиною системи, розмазується по всьому коду.

Це і є та сама забута ялинка.

Важливо розуміти: проблема не в тому, що вимоги змінюються. Це нормально. Проблема в тому, що архітектура спочатку не була спроєктована з розрахунком на подібну функцію. Найчастіше це наслідок недостатньої інженерної експертизи або відсутності зрілого архітектурного процесу. Рішення може працювати «тут і зараз», але в довгостроковій перспективі воно виявляється нераціональним і некоректним для конкретної системи.

Хороша архітектура — це не ідеальна схема на всі часи. Це система, у якіх мінімальна кількість подовжувачів, яка відповідає своїм цілям. Як розетка для ялинки: вона майже нічого не коштує на етапі планування, але економить гроші й нерви потім.

Логічне запитання: чи існує спосіб не забути спроєктувати справді важливі речі? Відповідь не є простою. Усе залежить від досвіду людей, які беруть участь у проєкті, і від того, наскільки вони розуміють, що саме важливо не проґавити.

У InterLink ми використовуємо кілька підходів, які допомагають зменшувати цей ризик. Один із них — публічність архітектурних рішень усередині команди. Коли виникає потреба в архітектурному рішенні, воно не впроваджується мовчки. Його виносять на обговорення, зокрема в Slack, де колеги можуть поставити незручні запитання і звернути увагу на потенційні проблеми. Це знижує ймовірність імпульсивних або локально оптимальних рішень, дозволяє згадати про edge cases.

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

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

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

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

Додатковим інструментом можуть бути й сучасні LLM. Їм можна надати опис проєкту, ключові user flow та архітектурні принципи й попросити вказати на слабкі місця: які сценарії не покриті, де функціональність виглядає неповною, де можливі проблеми з масштабуванням. Це не замінює інженерне мислення, але добре працює як підсилювач.

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

У цій статті ми не закликаємо проєктувати систему «на виріст», писати заглушки під гіпотетичні сценарії або ускладнювати архітектуру заздалегідь. Йдеться про інше. Ми говоримо про ті речі, які в реальних проєктах з’являються несистемно: як швидкі доповнення, обхідні рішення або «тимчасові» розширення, що з часом перестають бути тимчасовими.

У певний момент такі «подовжувачі» перестають бути просто додатковими функціями. Фактично це вже підсистема, але вона не спроєктована і не вбудована в архітектуру як частина цілого. Саме в цей момент має спрацьовувати тригер: це не ще одна фіча, це сигнал до переосмислення та реорганізації архітектури, щоб нова функціональність з’явилась у системі не випадково, а як її органічна частина.

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