Инструменты для защиты архитектуры

В заключительном уроке этого модуля мы поговорим об инструментах и ограничениях, которые защищают архитектуру проекта.

Даже идеально спроектированная архитектура со временем деградирует: увеличивается количество фич, растёт сложность, подключаются новые разработчики.

Чтобы защитить проект от хаоса, важно заранее ввести ограничения (constraints) и архитектурные правила (guardrails).

Typescript, eslint и т.д.

Перед тем как подключать более продвинутые инструменты важно выстроить самые базовые защитные механизмы.

В нашем учебном проекте они изначально установлены и у нас нет необходимости настраивать их. Однако, если вы работаете над проектом на чистом JavaScript или может в вашем проекте нет eslint задумайтесь о том чтобы добавить их.

TypeScript — это не просто «типизация для удобства». Это фундаментальный защитный слой, который:

1. Предотвращает ошибки данных. Например, позволяет предусмотреть обработку случаев, когда даные не пришли с сервера и т.д.
2. Защищает границы между модулями, обеспечивая согласованность контрактов между частями системы. Например, у вас не получится использовать компонент не передав ему все обязательные пропсы и т.д.
3. Предотвращает ошибки рантайма и скрытые баги, подсвечивая потенциально проблемные места.

ESLint — вторая линия защиты. Если TypeScript защищает от ошибок данных, то ESLint защищает структуру и форму кода. Его можно воспринимать как ревьюера, который следит за соблюдением правил и единообразием.

В зависимости от настроек ESLint может не только следить за форматированием кода, но и подсвечивать проблемы с доступностью, зависимостями хуков, небезопасные сравнения и т.д.

Кроме того он может поддержиать архитектурные решения, например, запретить использование глобальных переменных или запретить определенные импорты.

Таким образом, TypeScript и ESLint — это стартовый набор архитектурных защит, который нужно включать в проект с первого дня. Они работают на каждом шаге: от написания бизнес-логики до построения UI.

После того как эти базовые уровни защиты стоят, мы можем добавлять продвинутые инструменты о которых речь ниже.

Dependency Cruiser — главный страж архитектуры модулей

Dependency Cruiser это npm пакет, который позволяет автоматически проверять зависимости между файлами и модулями по правилам, определённым вами.

Например, мы решили, что модули нашего приложения должны быть независимыми, но что если один из разработчиков взял компонент из модуля restaurant и заиспользовал его в модуле search? Возможно, на начальном этапе не случиться ничего страшного, однако наш код станет более связным. Меняя что-то в модуле restaurant можно будет легко сломать search и т.д.

Dependency Cruiser позволяет избежать этого. Вот ссылка на страницу пакета в npm.

А сама документация лежит на Гитхабе. Там вы можете найти огромное количество примеров использования, порядок настройки правил и т.д.

Контроль производительности: Bundlesize и Performance Budgets

Bundlesize - это очередной инструмент, доступный в виде npm пакета. Он пригодится вам, если у вас есть жесткие рамки по производительности приложения. Bundlesize проверяет размер бандлов приложения и предотвращает попадание слишком тяжёлых зависимостей в проект или неконтролируемое разрастание модулей.

Более продвинутые инструменты, такие как Performance Budgets, берут во внимание не только размер бандла, но и другие метрики. Например, вы можете настроить целевые показатели Core Web Vitals метрик и при превышении пороговых значений вы получите алерт. Почитать подробнее о том как это работает можно в этой статье.

SonarLint — контроль когнитивной сложности

Еще один инструмент который хотелось бы упомянуть - SonarLint. Это расширение для VSCode которое работает похожим образом как и другие линтеры, но использует более продвинутые правила для анализа кода. SonarLint предупреждает о слишком сложных функциях, выявляет чрезмерную вложенность, предлагает способы уменьшить когнитивную сложность. Страничка расширения на маркетплейсе

Заключение

На самом деле подобных инструментов огромное множество и я привел лишьь некоторые из них. Основная мысль этого урока состоит в том, что вокруг любой системы можно и нужно формировать "защитную оболочку", которая помогает сохранять ясность структуры, качество модулей и предсказуемость поведения приложения.

Со временем проект будет расширяться, появятся новые модули, новые разработчики и новые требования, но правильно выстроенные ограничения обеспечат стабильность архитектуры и помогут команде двигаться быстрее, не боясь сломать фундамент. Именно так мы превращаем разовую красивую архитектуру в самоподдерживающуюся инженерную систему, которая живёт и развивается годами.