Коли люди роблять ремонт, вони майже завжди думають про велике: стіни, вікна, підлогу, меблі. А потім настає грудень, з’являється ялинка, гірлянда — і раптом з’ясовується, що розетки «тут не планувалися». Починаються подовжувачі, трійники, дроти через усю кімнату і універсальне виправдання: «Ну, потім якось вирішимо». Вирішити можна. Але дорого, негарно і незручно.
З програмною архітектурою відбувається рівно те саме.
На старті проєкту команда зазвичай зосереджується на ключовому функціоналі: основні модулі, бази даних, API, інтеграції. Усе виглядає логічно й охайно. Але якщо на цьому етапі не закласти важливі «дрібниці» — розширюваність, майбутні сценарії, точки зростання, — згодом вони починають з’являтися хаотично. Функціональність нарощується, архітектурні рішення ухвалюються несистемно, під тиском дедлайнів або конкретного запиту. У результаті те, що мало бути однією продуманою частиною системи, розмазується по всьому коду.
Це і є та сама забута ялинка.
Важливо розуміти: проблема не в тому, що вимоги змінюються. Це нормально. Проблема в тому, що архітектура спочатку не була спроєктована з розрахунком на подібну функцію. Найчастіше це наслідок недостатньої інженерної експертизи або відсутності зрілого архітектурного процесу. Рішення може працювати «тут і зараз», але в довгостроковій перспективі воно виявляється нераціональним і некоректним для конкретної системи.
Хороша архітектура — це не ідеальна схема на всі часи. Це система, у якіх мінімальна кількість подовжувачів, яка відповідає своїм цілям. Як розетка для ялинки: вона майже нічого не коштує на етапі планування, але економить гроші й нерви потім.
Логічне запитання: чи існує спосіб не забути спроєктувати справді важливі речі? Відповідь не є простою. Усе залежить від досвіду людей, які беруть участь у проєкті, і від того, наскільки вони розуміють, що саме важливо не проґавити.
У InterLink ми використовуємо кілька підходів,