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

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

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

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

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

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


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

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

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

Все.

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

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

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

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

Войти через центр авторизации
Похожие вопросы