Иногда мой босс будет жаловаться нам:
Почему нам нужно такое долгое время для реализации функции?
На самом деле эта функция была реализована в другом приложении раньше, вам просто нужно скопировать и вставить коды оттуда. Стоимость должна быть низкой.
Это действительно сложный вопрос, потому что коды копирования и вставки не так просты в моей точке зрения.
Есть ли веские причины объяснить это вашему нетехническому боссу?
Если вы обнаружили ошибку в коде для копирования-вставки, вам нужно будет исправить ее в любом месте, и вы надеетесь, что сможете их запомнить (это также относится к измененным требованиям).
Если вы сохраняете логику в одном месте, ее легче изменить при необходимости (поэтому, если вы решите, что приложение нуждается в обновлении, вы делаете это только в одном месте).
Расскажите своему начальнику о принципе DRY (не повторяйте сами).
То, что вы описываете, звучит как идеальное использование для библиотек, где вы используете общий код и сохраняете его только в одном месте.
Я бы только когда-либо копировал-вставлял код, если бы собирался реорганизовать его вскоре после этого, убедившись, что я позже извлек общий код, чтобы я мог использовать как можно больше логики. И вскоре после этого, я имею в виду минуты и часы спустя, а не дни и недели.
Вам было бы намного лучше использовать код, создав библиотеку, а не копируя код, используя копию и вставку.
Вы все равно получите преимущество в скорости перед повторной записью (посмотрите DRY), но у вас будет только одно место для поддержки кода.
Очевидная причина заключается в том, что вы берете на себя "долг" на будущее: любое изменение, которое вам когда-либо понадобится сделать в коде (а не только исправления, любые изменения), теперь будет вдвое дороже, потому что вам нужно обновить два места - и более рискованно, потому что вы в конце концов забудете одного из них. Другими словами, заставляя работать быстрее, в будущем ваша работа будет еще медленнее, что может быть хорошим бизнес-понятием, но обычно это не так.
Но более важная причина заключается в том, что предположение "это то же самое, что и есть", чаще всего неточно неправильно. Всякий раз, когда ваш код зависит от невысказанных предположений, чтобы быть верным, копирование его в другое место приводит к ошибкам, если эти предположения также не сохраняются на новом месте. Поэтому вставленный код часто ошибочен с самого начала, а не сразу после следующего изменения.
Конструктивный, скопированный код, безусловно, является катастрофой, потенциально вызывающей множество проблем в будущем. Но вы спрашиваете, почему сейчас вам требуется большая работа , ответ таков: потому что он никогда не копирует и не вставляет.
Если исходный код был написан для повторного использования в качестве довольно независимой библиотеки с учетом гибкости и использования клиентом - тогда это здорово, но не копировать, используя библиотеку кодов. Реальное копирование кода обычно выглядит примерно так:
Таким образом, существующий код, который нельзя использовать напрямую, в лучшем случае может служить хорошей ссылкой для написания аналогичного кода. Это, безусловно, не может быть отменено целиком и ожидается, что оно будет работать в совершенно другой системе. В общем, это безопасное предположение, что любой код, который был написан и завершен, должен быть запутан как можно меньше - даже когда это копия, а не сам оригинал.
Если вы хотите создать свой проект при копировании, вам нужно ввести код , чтобы начать с таким образом, чтобы обеспечить возможность повторного использования, без копирования этого оригинальный код и возиться с ним. Это стоит того, и если вы ожидаете своего босса, то вам обоим нужно убедиться в том, как вы разрабатываете и работаете в первую очередь.
копирование и вставка - это катастрофа, ожидающая своего появления. Ваш босс должен оценить цену доставки рано в связи с ценой скорого отказа от кода, отправленного конечному пользователю.
Если вы уже внедрили функции, и вам нужно их скопировать и вставить для повторного использования, это звучит так, будто вы сделали что-то неправильно. Не можете ли вы поместить эти функции в библиотеку, чтобы вы могли повторно использовать их без копирования/вставки?
Принцип DRY (не повторяйте сам): DRY на wikipedia.
"Каждая часть знания должна иметь одно, недвусмысленное, авторитетное представление внутри системы".
Это звучит для меня как худшее заблуждение вашего нетехнического босса, заключается в том, что ваша работа преимущественно печатается. Они думают, что вы можете сэкономить много времени, исключив типизацию.
Я думаю, что лучшее образование, которое вы могли бы дать этому человеку, - это указать всю работу, которую вы делаете, а не набирать. Даже если большая часть этой работы обычно происходит невидимо, в вашей голове, в то же время, что и набрав.
Конечно, устранение набора текста сэкономит некоторое время. Но тогда намного большая, непечатаемая часть вашей работы становится больше и съедает любое экономия времени и, кроме того.
Вы уверены, что ваш босс хочет услышать о принципе DRY, ошибках и других технических материалах?
Такие комментарии, которые вы обычно слышите, когда ваш босс или компания недооценили время, необходимое для завершения какого-либо проекта. И на основании неправильной оценки был подписан контракт и т.д. В большинстве случаев программисты не участвовали в оценках.
Почему это происходит? Иногда у спонсора проекта слишком малый бюджет. Возможно, бизнес-процесс, который вы автоматизируете с помощью программного обеспечения, не стоит усилий вашей команды. В таких случаях менеджеры обычно очень закрыты для плохих новостей. В начале проекта есть желаемое за действительное. Тогда менеджеры пытаются обвинить программистов. В вашем случае косвенно с помощью копирования и вставки. В крайних случаях это называется марш смерти.
Копирование и вставка кода обычно приводит к Программирование методом совпадения
Я думаю, что " другое приложение" является ключевым здесь, если другое приложение уже проверено и используется, оно должно не меняться, чтобы использовать общую библиотеку, поэтому вы не можете использовать общий код.
В одном приложении "копировать и вставлять" плохо, но между базами кода, которые разрабатываются разными командами или с разными циклами выпуска, "копировать и вставлять" может быть наилучшим вариантом.
Я работал в аналогичной компании. Будучи стажером, я тогда не знал, поэтому, когда я начал новый проект, мой босс также предложил вставить код из другого места. Ну, как вы думаете, все программное обеспечение было довольно беспорядочным, вплоть до того, что, когда вы пытались исправить ошибку, появились две новые ошибки.
Даже если у другого приложения уже есть необходимая функция, код для этой функции может просто не вписываться в ваше текущее приложение без серьезной перезаписи. Это как взять мотор Форда и попытаться вместить его в Toyota. Как правило, существует правило: если вам нужно изменить более 25% кода, который вы копируете, лучше (дешевле) переписать его с нуля.
Извлечение рассматриваемого кода в звукозаписывающую среду, но это может быть сложнее, чем кажется, в зависимости от того, как построена эта другая система. Например. код для этой функции может быть трудно извлечь, поскольку он взаимодействует с большим количеством другого кода нечистыми способами (например, путем доступа к большим количествам глобальных переменных и т.д.).
Сообщите своему боссу, что часть каждого имени переменной включает имя старого проекта, и теперь вы должны изменить их все вручную. Если ваш босс не знает (или хочет знать), почему копирование/вставка плохо, он может также полагать, что:)
Существуют компромиссы между скоростью разработки непосредственной функциональности перед вами (особенно когда приложение мало) и долгосрочными эксплуатационными расходами по мере роста приложения.
Скопировать и вставить быстрее для немедленной работы, но будет стоить вам дорого, так как приложение растет по размеру с точки зрения исправления ошибок и внесения изменений в систему и поддержания рабочих процессов между различными компонентами приложения.
Это аргумент, который владельцы бизнеса должны услышать. Это похоже на принятые затраты на поддержание парка транспортных средств, однако с программным обеспечением нарушенные аспекты архитектуры программного обеспечения, как правило, скрыты для бизнеса, и их могут видеть только разработчики.
Он прав, если бы команда реализовала аналогичную функциональность раньше, повторение будет намного проще во второй раз.
Однако, вероятно, вам следует объяснить, что каждое приложение отличается. Просто потому, что вы установили дверь в одном доме, это не значит, что вы можете установить еще одну дверь в другом доме в кратчайшие сроки - вы будете быстрее из-за опыта (# двери установлены), но все равно потребуется время, чтобы получить оборудование, установите дверцу, убедитесь, что она отвеса, и вверните ее в раму.
Да, самая большая проблема заключается в том, что это не просто копирование и вставка - его копия затем вставляет, а затем слегка изменяет.
Затем, когда один из вставленных вариантов имеет проблему, он изменяется. Затем позже изменяется другой вариант.
Затем вы узнаете, что все варианты должны измениться, потому что исходная копия имеет ошибки. Теперь вы хорошо и по-настоящему ввернуты, потому что все наклеенные области теперь не совпадают.
И разве вы не знаете этого, такое дрянное кодирование обычно почти полностью лишено комментариев.
Для меня разница в том, что когда у вас несколько копий кода, делающих то же самое, у вас есть куча кода. Когда у вас есть только одна часть кода, выполняющая каждую конкретную вещь, у вас есть система.
Поведение системы может быть изменено с помощью одноточечных изменений довольно легко - для изменения поведения кучи кода требуется куча кода.
Мне нравятся системы, а не куча кода.
в моей компании мы всегда работаем с классами и методами и делаем для них техническую документацию. Я думаю, что это лучшая практика, если вы можете использовать свои собственные поисковые приложения svn с хорошими ключами, чтобы найти класс методов, который использовался раньше:)