Задать вопрос
Ni55aN
@Ni55aN
программирование

Как объяснить клиенту, что копипаст — это плохо?

Речь идет о копипасте на уровне "из приложения в новое приложение".

Есть сайт A с N фичами. Ему потребовался дополнительный сайт B (причем на чужом домене) , который содержит от предыдущего N - 2 фичи, и еще пару своих (на самом деле, больше обертки над уже сущетвующими из A).

Принято решение на сайте A предоставлять API для B, таким образом на B будет только своя логика, и не требуется повторно имплементить существующие фичи. Как вариант, вынести код в общий удаленный пакет (npm или github), но все, что это дает - дополнительный менеджмент пакета и потребность в настройки окружения на бэке для B.

В итоге, эта идея клиенту не нравится, так как изменения на A или B могут повлиять на второй (что вполне справедливо). Даже несмотря на то, что фичи где-то на 90% одинаковы. Были предоставлены доводы начиная от "плохой практики" до необходимости внесения одних и тех же правок в двух местах, но это все было проигнорировано. Как поступить в данной ситуации?
  • Вопрос задан
  • 556 просмотров
Комментировать
Подписаться 2 Простой Комментировать
Пригласить эксперта
Ответы на вопрос 6
webinar
@webinar
Учим yii: https://youtu.be/-WRMlGHLgRg
что копипаст — это плохо

кому плохо?
Вы высказали свои мнения? Отлично. Теперь делаем то за что Вам платят. Будет свой проект со своим финансированием - будете делать как Вам хочется.
Ответ написан
6 комментариев
6 комментариев
@Sovigod
Я бы не назвал вашу ситуацию копипастом. Это форк проекта. В новом почти все такое же, но чуть другие фичи - и возможно он будет по другому развиваться (ну или умрет быстро).
Перекидывать коммиты с фичами между форками не будет сложно, если у вас в новом всего пара отличающихся фич.
Ответ написан
Комментировать
Комментировать
be_a_dancer
@be_a_dancer
Backend/Fullstack Developer
Рекомендую попытаться еще раз объяснить ему, что такое плохая практика и для чего вы хотите так поступить. Сошлитесь на авторов, которых все знают: Фраулер, банда четырех и так далее. Если он не поймет (а я частично согласен с ним - возможно внесение изменений в старый проект будет дороже и опаснее, особенно, если старый код не покрыт тестами), то делайте так, как скажет клиент. В данном случае именно ему решать, каким образом это сделать. Также вы можете отказаться от работы с ним.
Ответ написан
2 комментария
2 комментария
mad_nazgul
@mad_nazgul
Вообще-то клиент прав.
Если есть "общие" части, то они должны быть выделены в библиотеку/фреймворк.
А это немного другой уровень разработки.
И писать его немного сложнее.
Поэтому в данном случае дешевле простой копи-паст.
Ответ написан
4 комментария
4 комментария
BorLaze
@BorLaze
Java developer
Есть сайт A с N фичами. Ему потребовался дополнительный сайт B (причем на чужом домене) , который содержит от предыдущего N - 2 фичи, и еще пару своих (на самом деле, больше обертки над уже сущетвующими из A).


Не надо ничего копипастить.

Делаем абстрактный сайт О, в котором будут общие для А и Б фичи (те самые N-2 из А).

Сайт А наследует сайт О + 2 фичи, характерные для А.
Сайт В наследует сайт О + 2 фичи, характерные для В.

Все.

В дальшейшем, при разработке чего-то нового, смотрим, куда это добавить - если только для сайта А, тогда в А; если только для сайта В, тогда в В; если и туда и туда, тогда в О.

API - это лишняя связность между компонентами, которая в данном случае избыточна и вредна (как тут выше заметили, если падает сайт А, это не должно касаться сайта В).
Ответ написан
2 комментария
2 комментария
@bitrixworkshop
Никак. Если он уверен по каким-то своим причинам.

Отчасти можно говорить об удорожании сопровождения. Но это (удорожание) случится только при условии, что общие фичи на всем протяжении проекта (времени жизни обоих сайтов) должны быть одинаковыми. Если они будут и должны со временем расходиться то копипаст (форк) - единственное решение. И тогда клиент очень сильно прав. Может он просто не хочет говорить об этих соображениях, но они есть.
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Python developer
Bell Integrator
До 350 000 ₽
Разработчик программного обеспечения авионики
Котлин-Новатор • Санкт-Петербург
от 50 000 до 150 000 ₽
Ведущий разработчик программного обеспечения авионики
Котлин-Новатор
от 150 000 до 250 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Скрипт по работе с API и записи в MySQL данных (задача на сегодня)
18 апр. 2024, в 12:20
4000 руб./за проект
Настроить корпоративные ящики
18 апр. 2024, в 12:04
2000 руб./за проект
Сверстать сайт на Nextjs или Reactjs
18 апр. 2024, в 12:01
15000 руб./за проект
Ещё заказы