Почему "копировать и вставлять" код опасно?
Иногда мой начальник будет жаловаться нам:
Зачем нам нужно так много времени для реализации функции?
На самом деле, эта функция была реализована в другом приложении раньше, вам просто нужно скопировать и вставить коды оттуда. Стоимость должна быть низкой.
Это действительно сложный вопрос, потому что копировать и вставлять коды не так просто, на мой взгляд.
У вас есть веские причины, чтобы объяснить это своему нетехническому боссу?
18 ответов
Если вы обнаружите ошибку в своем коде копирования и вставки, вам нужно будет исправить ее в каждом месте, где вы это сделали, и надеяться, что вы сможете запомнить их все (это также относится к измененным требованиям).
Если вы храните логику в одном месте, ее легче изменить при необходимости (поэтому, если вы решите, что приложение нуждается в обновлении, вы делаете это только в одном месте).
Пусть ваш начальник прочитает о принципе СУХОГО (не повторяйте себя).
То, что вы описываете, звучит как идеальное использование для библиотек, где вы делитесь кодом и храните его только в одном месте.
Я скопировал бы и вставил бы код только в том случае, если вскоре намеревался провести его рефакторинг - убедившись, что позже я извлек общий код, чтобы я мог использовать как можно больше логики. И вскоре я имею в виду минуты и часы, а не дни и недели.
Вам было бы гораздо лучше поделиться кодом, создав библиотеку, а не копировать код с помощью копирования и вставки.
Вы по-прежнему получите преимущество в скорости перед перезаписью (ищите DRY), но у вас будет только одно место для поддержки кода.
Очевидная причина заключается в том, что вы берете на себя "долг" на будущее: любое изменение, которое вам когда-либо нужно будет внести в код (не просто исправление ошибок, любое изменение), теперь будет в два раза дороже, потому что вам нужно обновить два места - и более рискованным, потому что вы забудете один из них в конце концов. Другими словами, ускорение работы сейчас сделает вашу работу еще медленнее в будущем, что может быть хорошим деловым смыслом, но обычно это не так.
Но более важной причиной является то, что предположение "это то же самое, что и это" чаще всего ошибочно. Всякий раз, когда ваш код зависит от правильности невысказанных предположений, копирование его в другое место приводит к ошибкам, если эти предположения также не сохраняются на новом месте. Следовательно, вставленный код часто неверен с самого начала, а не только после следующего изменения.
Разработка кода с копированием кода - это, безусловно, катастрофа, которая может вызвать много проблем в будущем. Но вы спрашиваете, почему сейчас у вас много работы, ответ таков: потому что это не просто копирование и вставка.
Если исходный код был написан для повторного использования в качестве довольно независимой библиотеки с учетом гибкости и использования клиентом, то это здорово, но это не копирование, а использование библиотеки кода. Копирование реального кода обычно происходит примерно так:
- "Конечно, у меня уже есть код, который делает именно это!"
- "Подождите, какую из этих пяти версий кода я хочу использовать в качестве моего источника?"
- "Хммм, что делают все эти функции" util_func_023 "? Разве я не документировал их? Какие из них мне нужны сейчас?"
- "О, да, этот код использует Code Base Y. Думаю, мне нужно [ выбрать один: скопировать всю Code Base Y в мой новый проект / потратить день на освобождение одной функции, которую я хочу от Code Base Y / потратить неделю на освобождение одна функция, которую я хочу от Code Base Y]. "
- "Я скопировал все, ура!"
- "Почему это не работает?"
- Это та точка, где вы проводите часы / дни / недели отладки существующего кода, который похож на то, что вы хотите, вместо того, чтобы писать код, с которого вы действительно хотите начать.
Таким образом, существующий код, который нельзя использовать напрямую, в лучшем случае может послужить хорошим справочным материалом для написания подобного кода. Это, конечно, не может быть отменено целиком и ожидается, что он будет работать в совершенно другой системе. В целом, это безопасное предположение, что любой код, который был написан и завершен, должен быть испорчен как можно меньше - даже если это копия, а не сам оригинал.
Если вы хотите, чтобы ваш проект основывался на вставке копий, вы должны начать с кода таким образом, чтобы можно было легко использовать его повторно, без копирования исходного кода и возни с ним. Это стоит делать, и если это то, чего ожидает ваш начальник, то вы оба должны убедиться, что именно так вы спроектировали и работаете в первую очередь.
Копирование и вставка - это катастрофа, ожидающая своего появления. Ваш начальник должен заранее оценить стоимость доставки по отношению к цене того, что очень скоро сломанный код будет отправлен конечному пользователю.
Если вы уже реализовали эти функции и вам нужно скопировать и вставить их для повторного использования, похоже, вы сделали что-то не так. Разве вы не можете поместить эти функции в библиотеку, чтобы вы могли использовать их без копирования / вставки?
СУХОЙ принцип (не повторяй себя): СУХОЙ на википедии.
"Каждая часть знаний должна иметь одно, однозначное, авторитетное представление в системе".
Мне кажется, что худшее заблуждение, которое есть у вашего нетехнического босса, заключается в том, что ваша работа в основном печатается. Они думают, что вы можете сэкономить много времени за счет отказа от набора текста.
Я думаю, что лучшее образование, которое вы могли бы дать этому человеку, это указать на всю работу, которую вы выполняете, а не печатать. Даже если большая часть этой работы обычно происходит незаметно, в вашей голове, одновременно с набором текста.
Конечно, устранение набора текста сэкономит некоторое время. Но тогда гораздо большая, не набирающая текста часть вашей работы становится больше и съедает любое время, экономя и даже больше.
Вы уверены, что ваш начальник хочет услышать о принципе СУХОГО, ошибках и других технических вещах?
Такого рода комментарии вы обычно слышите, когда ваш начальник или компания недооценивают время, необходимое для завершения какого-либо проекта. И на основании неверной оценки был подписан контракт и т. Д. В большинстве случаев программисты не участвовали в оценках.
Почему это происходит? Иногда спонсор проекта имеет слишком маленький бюджет. Возможно, бизнес-процесс, который вы автоматизируете с помощью программного обеспечения, не стоит ваших командных усилий. В таких случаях менеджеры, как правило, очень закрыты для плохих новостей. В начале проекта есть желаемое за действительное. Тогда менеджеры пытаются обвинить программистов. В вашем случае косвенно с помощью копирования и вставки. В крайних случаях это называется маршем смерти.
Копирование и вставка кода обычно приводит к программированию по совпадению
Я думаю, что ключевым моментом здесь является " другое приложение ", если другое приложение уже протестировано и используется, его не следует изменять для использования общей библиотеки, поэтому вы не можете делиться с ним кодом.
В одном и том же приложении "копировать и вставлять" - это плохо, но между базами кода, разрабатываемыми разными командами или с разными циклами выпуска, "копировать и вставлять" может быть лучшим вариантом.
Даже если другое приложение уже имеет необходимую вам функцию, код этой функции может просто не вписаться в ваше текущее приложение без серьезной переписывания. Это все равно что взять мотор Форда и попытаться уместить его в Тойоте. Как правило, существует практическое правило: если вам нужно изменить более 25% копируемого кода, лучше (дешевле) переписать его с нуля.
Извлечение рассматриваемого кода в библиотеку звучит убедительно, но это может быть сложнее, чем кажется, в зависимости от того, как построена эта другая система. Например, код для этой функции может быть трудно извлечь, потому что он связывает много другого кода нечистыми способами (например, путем доступа ко множеству глобальных переменных и т. Д.)
Я работал в аналогичной компании. Будучи стажером, я тогда не знал лучше, поэтому, когда я начинал новый проект, мой начальник также предложил вставить код откуда-то еще. Ну, как вы можете подумать, все программное обеспечение было довольно беспорядочным, вплоть до того момента, когда вы пытались исправить ошибку, появлялись две новые ошибки.
Существует компромисс между скоростью разработки непосредственно перед вами функциональности (особенно, когда приложение небольшого размера) и более длительными затратами на обслуживание по мере роста приложения.
Копирование и вставка быстрее для немедленной функциональности, но дорого обойдутся вам по мере увеличения размера приложения, с точки зрения исправления ошибок и внесения изменений в масштабе всей системы и поддержания рабочих процессов между различными компонентами приложения.
Это аргумент, который владельцы бизнеса должны услышать. Это похоже на принятые затраты на содержание парка транспортных средств, однако с программным обеспечением нарушенные аспекты архитектуры программного обеспечения обычно скрыты для бизнеса и могут быть видны только разработчикам.
Да, самая большая проблема заключается в том, что это не просто копирование и вставка - его копирование затем вставляется, а затем слегка изменяется.
Затем, когда у одного из вставленных вариантов возникает проблема, он меняется. Затем, другой вариант меняется.
Затем вы обнаружите, что все варианты должны измениться, потому что в оригинальной копии были ошибки. Теперь вы хорошо и по-настоящему прикручены, потому что все вставленные области теперь не совпадают.
И разве вы не знаете, этот вид дерьмового кодирования обычно почти полностью лишен комментариев.
Для меня разница в том, что когда у вас есть несколько копий кода, выполняющих одно и то же, то у вас есть куча кода. Когда у вас есть только один кусок кода, выполняющий каждую конкретную вещь, тогда у вас есть система.
Поведение системы может быть легко изменено с помощью одноточечных модификаций - для изменения поведения группы кода требуется группа кода.
Мне нравятся системы, а не куча кода.
Скажите своему боссу, что часть имени каждой переменной включает в себя имя старого проекта, и теперь вам нужно изменить их все вручную. Если ваш босс не знает (или хочет знать), почему копирование / вставка плоха, он / она может с этим также поверить:)
Он прав, что если команда уже реализовала подобную функциональность, повторить это будет гораздо проще во второй раз.
Тем не менее, вы, вероятно, должны объяснить, что каждое приложение отличается. То, что вы установили дверь в одном доме, не означает, что вы можете установить другую дверь в другом доме в кратчайшие сроки - вы будете быстрее благодаря опыту (# двери установлены), но вам все равно потребуется время, чтобы получить оборудование, установите дверцу, убедитесь, что она отвесная, и вверните ее в раму.
В моей компании мы всегда работаем с классами и методами, и делаем техническую документацию для них. Я думаю, что это лучшая практика, если вы можете использовать свои собственные приложения для поиска SVN с хорошими ключами, чтобы найти класс метода, который использовался ранее:)