Дублирование кода или создание универсальных компонентов?

Время чтения - 5 мин.

Дата публикации 22.06.2022 (обновлено 28.05.2026)

Дублирование кода или создание универсальных компонентов?

Вы думаете, один универсальный компонент для всех ролей — это круто? Зря

Представьте: у вас три роли — Заказчик, Исполнитель и Администратор. У всех есть профиль, и все работают с проектами. Кажется логичным сделать один компонент для всех: форму профиля, список проектов, страницу проекта. Сэкономите время, да?

Нет. Это ловушка. Такое решение — бомба замедленного действия. В начале всё красиво, но первый же пожелание от бизнеса превратит код в минное поле. Я не раз видел, как проекты умирали под тяжестью «универсальных» монстров. Давайте разберем, почему это плохо и как сделать правильно. В итоге вы сэкономите кучу нервов и денег на поддержке.

Например, Заказчику нужно добавить поле «Бюджет проекта», а Админу — поле «Статус модерации». В одном компоненте это превратится в спагетти из условий if (role == 'customer'), которое будет страшно трогать. А представьте, если дизайн для Заказчика и Исполнителя должен отличаться? Придется пилить одну форму, которая выглядит по-разному для разных ролей. Ад, да?

Почему один компонент на всех — это плохо

Ветвления бизнес-логики. Каждая роль имеет свои нюансы. Заказчик и Админ могут редактировать проект, Исполнитель — только смотреть. Это порождает кучу условий внутри одного компонента.
Риски безопасности. Ошибка в коде — и Заказчик случайно получит права Админа. Одна лишняя проверка — и вы в зоне риска.
Сложность изменений. Хотите добавить «Заметки Заказчика»? Придется учесть, что это поле не должно показываться Исполнителю и Админу. Каждое изменение — это проверка под всеми ролями.
Проблемы с дизайном. Заказчику нужен красивый интерфейс, Админу — функциональный. В одном компоненте это совместить сложно.

Важно. Один универсальный компонент — это не про экономию, а про будущие проблемы. Любое изменение в таком «монстре» требует тестирования под всеми ролями. Один неверный коммит — и функционал сломается для всех.

Как я предлагаю решать: отдельные компоненты для каждой роли

Сразу закладывайте, что формы для разных ролей будут развиваться по-разному. Не бойтесь плодить компоненты. Это не дублирование кода, а инвестиция в будущее.

Вот как должно выглядеть разбиение:

Редактирование профиля Админа;
Редактирование профиля Заказчика;
Редактирование профиля Исполнителя;
Таблица проектов Админа;
Таблица проектов Заказчика;
Таблица проектов Исполнителя;
Форма проекта Админа;
Форма проекта Заказчика;
Форма проекта Исполнителя.

Да, на старте это кажется избыточным. Но поверьте: когда через полгода Заказчик попросит добавить «комментарии к проекту», вы просто добавите поле в его форму и не будете трогать остальные. Никаких страхов, что вы что-то сломаете у Админа.

Плюсы такого подхода:

Компоненты простые. Минимум ветвлений — мы сразу знаем, кто пришел и что ему можно.
Безопасность. В компоненте мы проверяем доступ к конкретным объектам. Риск ошибки минимален.
Изменения изолированы. Меняете для Админа — уверены, что у Заказчика ничего не упадет.
Дизайн под роль. Разметка заточена под конкретную роль, меньше кода.

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

И что, теперь плодить компоненты для каждой роли?

В данном примере — да. Но в общем случае нужно смотреть на будущее развитие.

Когда стоит разделять:

Роли кардинально разные (разные цели и доступы).
Роли будут по-разному развиваться (например, Заказчик и Агентство-Заказчик).
Бизнес-логика для ролей разная.

Когда можно оставить один компонент:

Роли очень похожи (Модератор и Админ).
Роли будут развиваться одинаково.
Доступы похожи, и риски от ошибки минимальны.

Главный принцип: изменения в компоненте для одной роли не должны влиять на другие. Если бухгалтер хочет поменять свой интерфейс — это не должно затрагивать формы Клиента.

Особенности подхода: как не уйти в дублирование

Разделение на компоненты не должно приводить к дублированию типовых действий. Выносите общую логику в отдельные функции или хранимые процедуры.

Например, у Админа и Модератора может быть одна форма проекта. Но у Админа на этой форме есть дополнительные таблицы и кнопки. Их можно реализовать как отдельные вложенные компоненты, доступные только Админу.

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

Заключение: простота поддержки — ваша выгода

Универсальный подход красиво выглядит только в теории. На практике поддерживать такой проект — хождение по минному полю. Каждая правка рискует сломать что-то для других ролей.

Данное решение критически важно для проекта. Оно определяет, насколько проект будет хрупким и сложным в поддержке. В некоторых случаях сверхуниверсальные компоненты после ряда правок становятся настолько сложными, что их проще переписать.

Принимайте правильные решения на старте — это упростит ваш продукт и уменьшит расходы на сопровождение. Если вы только начинаете, советую прочитать нашу статью про затраты на создание сайта — там много практических советов.

Теги разработчику (38)