Обновлено:
Сегодня мой ученик задал вот такой хороший вопрос:
Может кто-нибудь сталкивался с такой ситуацией в командной разработке.
Один фронт создал компонент. Второму фронту понадобился этот же компонент, но ему нужно изменить логику его работы, но если он её изменит, то у функционал первого фронта сломается?
Что в таком случае делать второму фронту?
Пытаться сделать компонент более переиспользуемым увеличивая количество логики внутри или создавать копию этого компонента с другой логикой?
Командными усилиями учеников мы пришли к двум вариантов ответов:
Есть несколько подходов, которые можно рассмотреть:
-
Переиспользование с параметрами или настройками: Попробуйте сделать компонент более гибким и параметризуемым. Разработайте его таким образом, чтобы части логики можно было настраивать снаружи компонента, например, через передачу параметров или использование свойств.
-
Создание расширенной версии: Если новая логика сильно отличается от оригинала и может привести к различному поведению, может быть разумным создать новую версию компонента. Основная идея останется, но внутренняя реализация будет подстроена под новые требования.
-
Изоляция изменений: Иногда возможно выделить часть компонента, которая будет отвечать только за изменяемую логику. Это позволит вам создать расширение или модификацию компонента без влияния на основной функционал.
-
Разделение на отдельные компоненты: Если изменения слишком существенны и концептуально отличаются, может быть лучше создать два отдельных компонента с разной логикой. Это поможет избежать путаницы и сохранит чистоту и понятность кода.
Выбор подхода зависит от конкретной ситуации, уровня изменений и архитектурных требований проекта. Важно также учитывать возможные последствия для существующего функционала и тестируйте изменения, чтобы убедиться, что они не ломают работу других частей системы." как то так )
У вас ранее был компонент А, и вам нужно получить в результате работы компоненты А1 Б В, где:
- А1 - компонент отвечающий за общую или базовую логику
- Б - А1 + описание логики присущее А
- В - А1 + описание новой бизнес логики
Обычно А1 описывают в максимально простом виде