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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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