Как объяснить клиенту, что копипаст — это плохо? Речь идет о копипасте на уровне "из приложения в новое приложение". Есть сайт A с N фичами. Ему потребовался дополнительный сайт B (причем на чужом домене) , который содержит от предыдущего N - 2 фичи, и еще пару своих (на самом деле, больше обертки над уже сущетвующими из A). Принято решение на сайте A предоставлять API для B, таким образом на B будет только своя логика, и не требуется повторно имплементить существующие фичи. Как вариант, вынести код в общий удаленный пакет (npm или github), но все, что это дает - дополнительный менеджмент пакета и потребность в настройки окружения на бэке для B. В итоге, эта идея клиенту не нравится, так как изменения на A или B могут повлиять на второй (что вполне справедливо). Даже несмотря на то, что фичи где-то на 90% одинаковы. Были предоставлены доводы начиная от "плохой практики" до необходимости внесения одних и тех же правок в двух местах, но это все было проигнорировано. Как поступить в данной ситуации?
В данной ситуации, можно попробовать объяснить клиенту, что использование копипаста в данном случае может привести к ряду проблем, таких как:
Дублирование кода: при использовании копипаста в обоих приложениях может возникнуть ситуация, когда при необходимости внесения изменений в функционал придется делать это в двух местах одновременно, что создаст лишнюю нагрузку для разработчиков и увеличит вероятность ошибок.
Несогласованность данных: если данные или функционал в одном приложении изменятся, но не будут соответственно изменены в другом, это может привести к непредсказуемым результатам и ошибкам в работе приложений.
Увеличение сложности поддержки: при наличии дублированного кода в двух приложениях увеличивается сложность поддержки и развертывания приложений, так как потребуется управлять изменениями в обоих местах.
Для решения данной проблемы, лучшим решением может быть создание общего API для обоих приложений, который будет содержать повторно используемую логику и функции. Это позволит избежать дублирования кода и упростит поддержку и разработку приложений.
Если клиент все равно настаивает на использовании копипаста, можно согласиться на его использование, но предупредить о возможных проблемах и рисках, которые могут возникнуть в дальнейшем. Важно также документировать все изменения и обновления в обоих приложениях, чтобы минимизировать возможные ошибки и проблемы в будущем.
В данной ситуации, можно попробовать объяснить клиенту, что использование копипаста в данном случае может привести к ряду проблем, таких как:
Дублирование кода: при использовании копипаста в обоих приложениях может возникнуть ситуация, когда при необходимости внесения изменений в функционал придется делать это в двух местах одновременно, что создаст лишнюю нагрузку для разработчиков и увеличит вероятность ошибок.
Несогласованность данных: если данные или функционал в одном приложении изменятся, но не будут соответственно изменены в другом, это может привести к непредсказуемым результатам и ошибкам в работе приложений.
Увеличение сложности поддержки: при наличии дублированного кода в двух приложениях увеличивается сложность поддержки и развертывания приложений, так как потребуется управлять изменениями в обоих местах.
Для решения данной проблемы, лучшим решением может быть создание общего API для обоих приложений, который будет содержать повторно используемую логику и функции. Это позволит избежать дублирования кода и упростит поддержку и разработку приложений.
Если клиент все равно настаивает на использовании копипаста, можно согласиться на его использование, но предупредить о возможных проблемах и рисках, которые могут возникнуть в дальнейшем. Важно также документировать все изменения и обновления в обоих приложениях, чтобы минимизировать возможные ошибки и проблемы в будущем.