Зміст
Коротко
Arcovia — проєкт із відкритим кодом для аналізу архітектури застосунків на React і Next.js. Він створює інтерактивний HTML-звіт: карту залежностей, проблемні модулі, пояснення оцінки та рекомендації щодо наступного рефакторингу.
Автор зібрав першу версію за вихідні на хакатоні OpenAI. Ключова ідея полягає в тому, що статичний аналіз не має перетворюватися на непрозорий вердикт: оцінку формують відтворювані правила, а не мовна модель.
Що сталося
У фронтенд-команд уже є інструменти для локальних проблем: ESLint помічає підозрілі конструкції, форматер вирівнює стиль коду, а сервіси якості показують порушення правил. Проте у великому застосунку лишається питання вищого рівня: які частини системи стають центрами надмірної зв'язаності й де супровід починає коштувати дорожче.
Arcovia читає вихідний код, розбирає його синтаксичне дерево та збирає модель проєкту. Далі вона будує граф імпортів, застосовує набір правил і формує звіт. У ньому є загальна оцінка стану архітектури, розподіл балів за категоріями та пояснення чинників, що вплинули на результат.
Серед виявлюваних ознак автор називає надто великі модулі й компоненти, глибоку вкладеність JSX, дубльовані імпорти, невикористані експорти, модулі без зв'язків, а також вузли з надмірною кількістю вхідних чи вихідних залежностей. Окремо такий сигнал не завжди означає помилку; цінність звіту — у поєднанні цих відомостей і визначенні пріоритетів.
Чому це важливо
Архітектурні проблеми рідко з'являються через одну велику зміну. Частіше компонент поступово перебирає нові обов'язки, спільний модуль стає точкою тяжіння імпортів, а тимчасовий обхідний шлях закріплюється в кількох місцях. Коли це стає помітним під час огляду коду, виправлення вже може торкатися значної частини застосунку.
Зведена оцінка корисна лише разом із поясненням. Команді недостатньо почути, що проєкт отримав 62 бали: вона має бачити, які правила спрацювали, які файли дали найбільший внесок і чому саме ці зв'язки важливіші за інші. Arcovia намагається зробити таку розмову предметною, а не підмінити архітектурне рішення числом.
Детермінований підхід тут принциповий. Один і той самий стан проєкту повинен давати однаковий результат, аби звіти можна було порівнювати між гілками та випусками. Мовна модель згодом може допомогти пояснити висновки або запропонувати способи перебудови, але не має бути єдиним джерелом оцінки.
На практиці
Інструмент можна запустити в корені проєкту командою npx arcovia analyze .. Перш ніж робити звіт частиною постійного процесу, варто перевірити його на знайомому коді й домовитися, які сигнали справді важливі саме вашій команді.
- Почніть із графа залежностей: знайдіть модулі, через які проходить незвично багато зв'язків, і перевірте, чи не змішалися в них різні обов'язки.
- Зіставте великі компоненти з історією змін. Якщо файл часто змінюють через не пов'язані між собою причини, він може бути добрим кандидатом на поділ.
- Не перетворюйте оцінку на заборону випуску. Використовуйте її як привід для огляду та спосіб побачити структурні зміни після великої задачі.
- Зберігайте звіти для важливих гілок. Тоді погіршення або поліпшення буде видно за конкретними залежностями й правилами, а не за враженням.
У планах Arcovia — запуск у GitHub Actions, історія звітів, розширення для VS Code, порівняння проєктів і панелі для команд. Ці можливості все одно потребуватимуть перевірки на реальних репозиторіях: правила архітектури та їхня вага залежать від продукту й команди.
Підсумок
Arcovia цікава не обіцянкою «виправити архітектуру за допомогою ШІ», а поділом ролей. Код і залежності аналізуються за зрозумілими правилами, а інтелектуальні помічники можуть зробити висновки звіту яснішими та прискорити обговорення варіантів.
Для React і Next.js-проєктів це може стати додатковим шаром між лінтером та архітектурним оглядом. Якщо оцінка лишатиметься пояснюваною, вона допоможе завчасно помітити накопичену зв'язаність, а не стане автоматичним вироком коду.