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

Question

[Vitaliy]

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

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

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

В итоге, эта идея клиенту не нравится, так как изменения на A или B могут повлиять на второй (что вполне справедливо). Даже несмотря на то, что фичи где-то на 90% одинаковы. Были предоставлены доводы начиная от "плохой практики" до необходимости внесения одних и тех же правок в двух местах, но это все было проигнорировано. Как поступить в данной ситуации?

Answer 1

[Максим Тимофеев]

что копипаст — это плохо

кому плохо?
Вы высказали свои мнения? Отлично. Теперь делаем то за что Вам платят. Будет свой проект со своим финансированием - будете делать как Вам хочется.

Comments

[Vitaliy]

кому плохо?

разработчикам.

по вашей логике любой пациент может прийти в больницу и сказать как его лечить. А что в итоге? Останутся виноваты врачи, так как пациент сказал ампутировать ему ногу, так как она болит, а потом пришить, когда перестанет болеть?

[Максим Тимофеев]

Виталий Столяров,

разработчикам.

Вам разработчики платят или заказчик? Вы объяснили, что это в будущем принесет доп расходы - все. Не внял, его ответственность. Ваша ответственность предупредить и сделать как попросили.

Врачи не могут без согласия пациента что-то делать, даже если им очень хочется и это очень надо для пациента. Но тут другая история. Не верная параллель.

[Vitaliy]

Максим Тимофеев, вы не понимаете аналогии? Пациент - клиент, врачи - исполнители, нога - фичи, отрезать - implement

[Максим Тимофеев]

Виталий Столяров, нет, это Вы не знаете как работают врачи. И не понимаете, что людям платят за достижение результата. Даже если этот результат Вам кажется странным или вредным. Есть люди которые рога себе вживляют. Доктор может предупредить, что так не стоит делать. Но он пластический хирург и профессионал, поэтому выполнит свою работу в любом случае. Так и Вы. Будьте профи. Предупредили и сделали.
Чужие идиотизмы не Ваша ответственность.

[Vitaliy]

Максим Тимофеев, то есть как для аутсорс компании под конец, когда совсем будет тяжко поддерживать проект, можно просто отказаться от этого (ну или повысить рейт) со словами "а мы предупреждали"?

[Максим Тимофеев]

Виталий Столяров, конечно. Это моя дежурная фраза "я предупреждал". Мои постоянные клиенты даже не спорят, когда я вношу свои 5 копеек, так как знают на практике, что я прав в 99% случаев. Но для понимания этого они должны наступить на эти грабли раз 5. Вы предлагаете не наступать, они хотят. Ну как тут отказать. Тем более, что для Вас в итоге это больше работы и денег как следствие. Хотят люди переплачивать - на здоровье. Предупредили, что этим закончится - все. Вы профи предугадываете события, но делаете так как просит клиент.

Answer 2

[Andrey Shatokhin]

Я бы не назвал вашу ситуацию копипастом. Это форк проекта. В новом почти все такое же, но чуть другие фичи - и возможно он будет по другому развиваться (ну или умрет быстро).
Перекидывать коммиты с фичами между форками не будет сложно, если у вас в новом всего пара отличающихся фич.

Answer 3

[Сергей Попов]

Рекомендую попытаться еще раз объяснить ему, что такое плохая практика и для чего вы хотите так поступить. Сошлитесь на авторов, которых все знают: Фраулер, банда четырех и так далее. Если он не поймет (а я частично согласен с ним - возможно внесение изменений в старый проект будет дороже и опаснее, особенно, если старый код не покрыт тестами), то делайте так, как скажет клиент. В данном случае именно ему решать, каким образом это сделать. Также вы можете отказаться от работы с ним.

Comments

[Vitaliy]

можно вообще самосознательно делать одни и те же фичи дольше. Все равно почасовая ставка, вот только он не останется в плюсе.
Тестирование, кстати, он тоже игнорирует. По крайней мере было предложено написать e2e, взамен чего они сейчас тратят по 3 дня на мануальное

[Константин Нагибович]

Сошлитесь на авторов, которых все знают: Фраулер, банда четырех и так далее.

Так себе аргумент при общении с бизнесом.

Answer 4

[Ерлан Ибраев]

Вообще-то клиент прав.
Если есть "общие" части, то они должны быть выделены в библиотеку/фреймворк.
А это немного другой уровень разработки.
И писать его немного сложнее.
Поэтому в данном случае дешевле простой копи-паст.

Comments

[Vitaliy]

вначале конечно дешевле, но речь идет о продолжительной поддержке обеих сайтов

[Ерлан Ибраев]

Виталий Столяров, В продолжительной - тем более лучше "разделять".
Т.е. оптимальнее всего создать общую библиотеку, на основе которой делать сайты.
Чем пытаться сделать универсального монстра.

Скажем так у меня был опыт написания двух "одинаковых" порталов.
По мере "уточнения ТЗ", оказалось, что они нифига не одинаковые.

Хотя никто вам не мешает самому пройтись по граблям. :-)

[Vitaliy]

> Чем пытаться сделать универсального монстра.

было же сказано, что 90% функционала - одинаковы. Как только это будет стремиться к уменьшению - да, согласен - нужно разделять

[Ерлан Ибраев]

Виталий Столяров, ИМХО "обьеденить" будет проще, чем "разъеденить" без копи пасты.

Answer 5

[BorLaze]

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

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

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

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

Все.

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

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

Comments

[Vitaliy]

что подразумевается под наследованием? Может просто расшаренная кодовая база в отдельном сабмодуле (git) или пакете?

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

для клиента остается проблема того, что общая фича для А и В может при допиливании ее под А может не вписаться в картину В. Но тут скорее проблема с требованиями и их анализом (или просто их хотелками), так как они в любой момент могут все переиначить (пару раз точно было, когда приходилось уже определенный как реюзабл компоненты переписывать)

[Vitaliy]

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

согласен, тогда останется только выносить общие модули и умножить время эстимейта на полтора-два

Answer 6

[Анатолий Кирсанов]

Никак. Если он уверен по каким-то своим причинам.

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