Чем опасно «копирование и вставка» кода? [закрыто]


130

Иногда мой начальник нам жалуется:

Почему нам нужно столько времени, чтобы реализовать функцию?

Собственно, раньше эта функция была реализована в другом приложении, вам просто нужно скопировать и вставить коды оттуда. Стоимость должна быть невысокой.

Это действительно сложный вопрос, потому что копировать и вставлять коды, на мой взгляд, не так уж и просто.

Есть ли у вас веские причины объяснить это своему начальнику, не имеющему технического образования?


19
похоже, что вместо того, чтобы копировать и вставлять код из ваших предыдущих приложений в новое, вы снова и снова переписываете одни и те же функции. Я думаю, что принцип DRY больше ориентирован на то, чтобы не дублировать одни и те же функции во всей системе, но повторное использование кода из других приложений лучше, чем его переписывание.
Carson Myers

5
Потому что каждый раз, когда вы копируете и вставляете код, детеныш тюленя погибает.
DeadlyChambers 01

@CarsonMyers Только если компонент многоразовый. И это должно соответствовать текущему контексту.
Sreekanth Karumanaghat 08

Ответы:


171

Если вы обнаружите ошибку в коде копирования и вставки, вам нужно будет исправить ее в каждом месте, где вы это делали, и надеяться, что вы сможете их все запомнить (это также относится к измененным требованиям).

Если вы сохраните логику в одном месте, ее будет легче изменить при необходимости (поэтому, если вы решите, что приложение нуждается в обновлении, вы делаете это только в одном месте).

Пусть ваш босс прочитает о принципе DRY (не повторяйтесь ).

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

Я бы скопировал и вставил код только в том случае, если бы вскоре после этого намеревался провести его рефакторинг - убедившись, что позже я извлечу общий код, чтобы я мог повторно использовать как можно больше логики. И под вскоре после этого я подразумеваю минуты и часы спустя, а не дни и недели.


41
+1. Дело в том, что копирование и вставка обходятся дешево для решения сиюминутной проблемы. Настоящая проблема заключается в том, что в среднесрочной / долгосрочной перспективе стоимость поддержки дублированного кода намного выше, чем хорошо продуманный код
Паоло

7
Это не просто ошибка; требования программы могут измениться. Я поменял четыре места из пяти, где раньше что-то нужно было поменять.
Дэвид Торнли,

1
Если вы можете копировать и вставлять по запросу и отслеживать, где дубликаты легко либо абстрагироваться, либо обновлять их, тогда копирование и вставка - неплохая вещь. См. Обсуждение обнаружения клонов на сайте www.semanticdesigns.com/Products/Clone для получения дополнительных сведений и инструментов, которые могут это сделать.
Ира Бакстер,

4
Их много ifs, и большинство инструментов на данный момент не поддерживает обнаружение клонов.
Oded

2
Жил-был программист, который работал в ESA . Он работал над программным обеспечением для ракеты Ариан-5 и использовал метод копирования-вставки. Потом с ... происходит
Хаулет

25

Было бы гораздо лучше поделиться кодом, создав библиотеку, чем копировать код с помощью копирования и вставки.

Вы по-прежнему получите преимущество в скорости по сравнению с повторной записью (см. СУХОЙ), но у вас будет только одно место для поддержки кода.


1
Мне просто любопытно, зачем вам «сокращать» код, если все, что вам нужно сделать, это его дублировать?
dpp

Хорошая точка dpp. Под редакцией!
CResults

12

Очевидная причина заключается в том, что вы берете на себя «долг» за будущее: любые изменения, которые вам когда-либо понадобятся в коде (не только исправления ошибок, любые изменения), теперь будут в два раза дороже, потому что вам нужно обновить два места - и более рискованно, потому что в конце концов вы забудете одну из них. Другими словами, если заставить его работать быстрее сейчас, ваша работа в будущем станет еще медленнее, что может быть хорошим бизнес-смыслом, но обычно не так.

Но более важная причина заключается в том, что предположение «это то же самое, что и это» чаще всего тонко ошибочно. Каждый раз, когда ваш код зависит от невысказанных предположений, его копирование в другое место приводит к ошибкам, если эти предположения также не выполняются в новом месте. Поэтому вставленный код часто бывает неправильным с самого начала, а не сразу после следующего изменения.


11

С точки зрения дизайна, скопированный код - это определенно катастрофа, способная вызвать множество проблем в будущем. Но вы спрашиваете , почему это займет у вас много работы прямо сейчас , ответ: потому , что он никогда не просто копировать и вставлять.

Если исходный код был написан для повторного использования, как довольно независимая библиотека, с учетом гибкости и использования клиента - тогда отлично, но это не копирование, а использование библиотеки кода. Реальное копирование кода обычно выглядит примерно так:

  • «Конечно, у меня уже есть код, который делает именно это!»
  • «Подождите, какую из этих пяти версий кода я хочу использовать в качестве источника?»
  • «Хммм, а что делают все эти функции 'util_func_023'? Разве я их не задокументировал? Какие из них мне нужны сейчас?»
  • "О, да, этот код использует Code Base Y. Думаю, мне нужно [ выбрать один: скопировать всю Code Base Y в мой новый проект / потратить день на извлечение одной функции, которую я хочу из Code Base Y / потратить неделю на извлечение одна функция, которую я хочу из Code Base Y] ".
  • "Я все скопировал, ура!"
  • "Почему это не работает?"
  • Это момент, когда вы тратите часы / дни / недели на отладку существующего кода, который похож на то, что вы хотите, вместо того, чтобы писать код, с которого вы действительно хотите начать.

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

Если вы хотите основать свой проект на копировании-вставке, вам нужно для начала код таким образом, чтобы его можно было легко использовать повторно, не копируя исходный код и не возиться с ним. Это стоит сделать, и если это то, чего ожидает ваш босс, то вам обоим нужно в первую очередь убедиться, что именно так вы проектируете и работаете.


9

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


9

Если вы уже реализовали эти функции и вам нужно скопировать и вставить их для повторного использования, похоже, что вы сделали что-то не так. Разве вы не можете поместить эти функции в библиотеку, чтобы вы могли повторно использовать их без копирования / вставки?


8

Принцип DRY (Don't Repeat Yourself): DRY в википедии .

«Каждая часть знания должна иметь единственное, недвусмысленное и авторитетное представление в системе».

другая ссылка .


Это все равно что сказать: «Никогда не втыкайте нож в горло мужчине», что звучит как очень хорошее правило. Пока вы не поймете, что врач ДОЛЖЕН нарушить это правило, чтобы выполнить трахиотомию для спасения жизни мужчины (если он не может дышать, возможно, из-за анафилаксии, сильной аллергической реакции). У каждого правила есть исключение (кроме, может быть, этого - что у каждого правила есть исключение). Следовательно, каждое правило должно иметь причину и когда, а также список исключений, все прилагается, для истинной «инженерной» реальности, что истинный ответ, это зависит от ...
MicroservicesOnDDD

Итак ... когда вы НЕ подписываетесь на DRY? Я постоянно борюсь с этим на моей текущей работе, которая связана с прошивкой, и ответ заключается в том, что мы «разворачиваем циклы» и делаем другие вещи, потому что это «улучшает производительность». У нас очень неглубокая иерархия наследования, и мы используем большинство классов напрямую, вместо того, чтобы создавать их подклассы, и ... ... мы часто используем копирование и вставку. И я ненавижу это, потому что из-за этого нашу кодовую базу сложнее понять и сложнее поддерживать. Но у нас есть свои причины, и они приемлемые. Мы не единственные заинтересованные стороны. А найти правильный баланс - это больше искусство.
MicroservicesOnDDD

7

Мне кажется, что худшее заблуждение вашего нетехнического начальника состоит в том, что ваша работа в основном печатает. Они думают, что можно сэкономить много времени, отказавшись от набора текста.

Я думаю, что лучшее образование, которое вы могли бы дать этому человеку, - это указать на всю работу, которую вы делаете, но не печатаете. Даже если большая часть этой работы обычно происходит незримо, в вашей голове, одновременно с набором текста.

Конечно, отказ от набора текста сэкономит время. Но затем гораздо большая часть вашей работы, не связанная с набором текста, становится все больше и съедает любую экономию времени и многое другое.


4

Вы уверены, что ваш босс хочет слышать о принципе DRY, ошибках и других технических вещах?

Подобные комментарии вы обычно слышите, когда начальник или компания недооценили время, необходимое для завершения проекта. И на основании ошибочной оценки был подписан контракт и т. Д. В большинстве случаев программисты не привлекались к оценке.

Почему так происходит? Иногда у спонсора проекта слишком маленький бюджет. Возможно, бизнес-процесс, который вы автоматизируете с помощью программного обеспечения, не стоит усилий вашей команды. В таких случаях менеджеры обычно очень закрыты для плохих новостей. В начале проекта есть принятие желаемого за действительное. Затем менеджеры пытаются обвинить программистов. В вашем случае косвенно через копирование и вставку. В крайнем случае это называется маршем смерти .


3

Копирование и вставка кода обычно приводит к программированию по совпадению


Я считаю, что эта статья написана исключительно плохо. Повествование остается абстрактным, поэтому не может пролить свет на дело, за исключением того факта, что Фред работает итеративно. Одна из очевидных проблем Фреда заключается в том, что он не имеет хорошего представления об общей архитектуре. К сожалению, это очень часто случается, когда мы работаем с недокументированным устаревшим кодом, когда ноу-хау теряется. Ссылки на дизайн по контракту и ассертивное программирование довольно хороши, но, к сожалению, даже после них примеры / упражнения остаются без объяснения.
mapto

3

Я думаю, что « другое приложение » является ключевым здесь, если другое приложение уже протестировано и используется, его не следует изменять для использования общей библиотеки, поэтому вы не можете делиться с ним кодом.

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


Хотя я вижу, что нет смысла выпускать обновление для другого приложения только для того, чтобы использовать библиотеку, вероятно, было бы неплохо хотя бы внести необходимые изменения в ветку функций. Это даст вам некоторую уверенность в том, что интерфейс библиотеки был достаточно общим, по крайней мере, для двух рассматриваемых приложений, и позволит вам объединить изменения в подходящий момент в цикле выпуска.
SamB

2

Я работал в аналогичной компании. Когда я был стажером, тогда я не знал лучшего, поэтому, когда я начал новый проект, мой начальник также предложил вставить код откуда-то еще. Что ж, как вы можете подумать, все программное обеспечение было довольно беспорядочным, вплоть до того, что, когда вы попытались исправить ошибку, появились две новые ошибки.


2

Даже если в другом приложении уже есть необходимая вам функция, код этой функции может просто не вписаться в ваше текущее приложение без серьезного переписывания. Это все равно, что взять двигатель Ford и попытаться уместить его в Toyota. Как правило, существует практическое правило: если вам нужно изменить более 25% кода, который вы копируете, лучше (дешевле) переписать его с нуля.

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


1

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


1

Да, самая большая проблема в том, что это не просто копирование и вставка - это копирование, затем вставка и небольшие изменения.

Позже, когда в одном из вставленных вариантов возникает проблема, он изменяется. Позже меняют другой вариант.

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

И разве вы не знаете, такое дерьмовое кодирование обычно почти полностью лишено комментариев.

На мой взгляд, разница в том, что когда у вас есть несколько копий кода, выполняющих одно и то же, у вас остается лишь кучка кода. Когда у вас есть только один фрагмент кода, выполняющий каждую конкретную задачу, у вас есть система.

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

Мне нравятся системы, а не набор кода.


1

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

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

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


0

Он прав в том, что если команда реализовывала подобный функционал раньше, повторить его во второй раз будет намного проще.

Однако вам, вероятно, следует объяснить, что каждое приложение отличается. Тот факт, что вы установили дверь в одном доме, не означает, что вы можете установить еще одну дверь в другом доме в кратчайшие сроки, квартира - вы будете быстрее из-за опыта (установлено # дверей), но все равно потребуется время, чтобы получить оборудование , установите дверь, убедитесь, что она ровная, и прикрутите ее к раме.


0

В моей компании мы всегда работаем с классами и методами, составляем для них техническую документацию. Я думаю, что это лучшая практика, если вы можете использовать свои собственные поисковые приложения svn с хорошими ключами, чтобы найти класс метода, который использовался раньше :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.