Зоопарк технологій у проєктах: що це, причини та методи

Що таке зоопарк технологій у проєкті

Зоопарк технологій — ситуація, коли в одному проєкті або компанії використовується надмірна кількість різнорідних інструментів, що вирішують одне й те саме завдання. Наприклад, три різних HTTP-клієнти (Alamofire, OkHttp, Ktor), два state manager (Redux, MobX) і три бази даних (Realm, CoreData, SQLite).

Відмінність зоопарку від усвідомленого вибору різних інструментів для різних завдань — у відсутності стратегії. Якщо команда A обирає React Native, команда B — Flutter, а команда C — Kotlin Multiplatform без спільного рішення — це зоопарк. Різноманіття саме по собі не шкідливе, шкідлива його безконтрольність.

Кожен новий стек у проєкті збільшує cognitive load для розробників. Щоб ефективно працювати, потрібно пам’ятати нюанси всіх використовуваних технологій. За даними Google (2024), перемикання контексту між різними стеками знижує продуктивність розробника на 23% у порівнянні з роботою в єдиному технологічному середовищі.

Причини виникнення технологічного зоопарку

Децентралізовані рішення — основна причина. Кожна команда обирає технології під свій проєкт без огляду на загальну стратегію. Backend-команда використовує Kotlin, ML-команда — Python, mobile-команда — Flutter. Окремо рішення вірні, але разом вони створюють зоопарк.

Mergers & Acquisitions (M&A) — коли компанія поглинає іншу, технологічні стеки об’єднуються. Дві системи вирішують одні завдання по-різному. Приклад: після покупки стартапу велика компанія отримує його стек на Ruby on Rails, хоча внутрішній стандарт — Java Spring. Виникає питання: переписувати чи підтримувати два стеки паралельно.

Зміна модних технологій — кожен цикл хайпу додає новий стек. У 2015 всі писали на AngularJS, у 2017 — на React, у 2020 — на Svelte. Без дисципліни проєкт збирає шари різних епох. Legacy-модулі, які працюють, але не підтримуються, додають різнорідності без можливості її швидко усунути.

Чим небезпечний зоопарк для команди та бізнесу

Онбординг нових розробників перетворюється на вивчення 5+ різних технологій замість однієї. Замість тижня на занурення в проєкт новачок витрачає місяць, щоб освоїти всі використовувані інструменти. Time-to-productivity зростає пропорційно кількості стеків у проєкті.

Перемикання контексту — розробник, який працює з 3+ стеками протягом дня, витрачає до 30% часу на відновлення контексту після кожного перемикання. За даними University of California (2023), після кожного перемикання потрібно 23 хвилини для повернення до вихідного рівня продуктивності. При 5 перемиканнях на день — майже 2 години втрачено.

Ризики безпеки — кожен стек потребує оновлень, моніторингу вразливостей та знання best practices. Команда не може бути експертом в усіх технологіях одночасно. Dependency fatigue — коли кількість використовуваних бібліотек перевищує можливість команди їх відстежувати та оновлювати — пряма загроза безпеці продукту.

Складність інфраструктури — CI/CD потрібно налаштувати для кожного стеку. Різні системи збірки (Gradle, CocoaPods, npm, pip), різні вимоги до середовища виконання. Інфраструктурна команда витрачає ресурси на підтримку різнорідних пайплайнів замість їх покращення.

Як діагностувати проблему в проєкті

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

Technology Radar — метод ThoughtWorks, який розділяє технології на 4 квадранти: Adopt, Trial, Assess, Hold. Adopt — рекомендовані стеки, Trial — експериментальні, Assess — на оцінці, Hold — не рекомендовані до використання. Приклад: Flutter в Adopt, React Native в Hold — командам зрозуміло, що обирати.

Метрика вартості підтримки — оціни, скільки інженерних годин витрачається на підтримку кожного стеку на місяць. Якщо стек споживає 10% ресурсів, але використовується в 2% модулів — він кандидат на заміну. Heat map стеку з осями «кількість проєктів» vs «складність підтримки» наочно показує проблемні зони.

Методи стандартизації технологічного стеку

Architecture Decision Records (ADR) — документування архітектурних рішень з обґрунтуванням вибору технології. Кожен ADR містить контекст, розглянуті альтернативи та аргументи на користь вибору. Michael Nygard (2022) популяризував цей підхід, і сьогодні ADR — стандарт для команд, які контролюють технологічне різноманіття.

Technology Review Board — комітет з провідних розробників, який затверджує нові технології в проєкті. Рішення приймається на основі критеріїв: сумісність з існуючим стеком, community support, cost of migration, talent availability. Spotify використовує подібний комітет з 2018 року.

Шлюз для нових проєктів — правило: будь-який новий сервіс або модуль використовує лише затверджений стек. Винятки можливі через ADR з обґрунтуванням. Приклад: новий мікросервіс можна писати на Kotlin тільки якщо команда доведе, що Java не підходить для цього завдання. Безбар’єрне використання будь-яких технологій заборонено.

Поетапне скорочення різнорідності стеків

Фаза 1: Заморозка — припиняються нові проєкти на непідтримуваних стеках. Для кожного стеку з Hold-квадранту встановлюється дата end-of-life. Нова функціональність пишеться тільки на approved-стеках. Legacy-модулі залишаються працювати, але не розширюються.

Фаза 2: Консолідація — для кожного завдання обирається один інструмент. Один HTTP-клієнт, один state manager, одна база даних. Модулі на альтернативних стеках плануються до міграції за пріоритетом. Strangler Fig pattern — основний метод заміни без зупинки системи.

Фаза 3: Міграція — кожен спринт команда виділяє 20% часу на переписування критичних модулів з застарілих стеків на затверджені. Target architecture фіксується в документі і не змінюється без рішення комітету. Процес займає від 6 до 24 місяців залежно від масштабу зоопарку.

Приклад: міграція HTTP-клієнтів

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}