Вы правы - копирование-вставка прекрасно работает, и DRY не имеет смысла, когда ваша задача - создать программу, для которой ни копируемый шаблон, ни копия не будут нуждаться в поддержке или развитии в будущем. Когда эти два программных компонента имеют совершенно разный жизненный цикл, объединение их вместе путем рефакторинга общего кода в общую библиотеку, которая сама находится в стадии интенсивной разработки, может действительно иметь непредсказуемые последствия для усилий. С другой стороны, при копировании разделов кода внутри одной программы или программной системы все эти части обычно имеют одинаковый жизненный цикл. Ниже я проиллюстрирую, что это значит для СУХОГО и управления проектами.
Серьезно, существует множество таких программ: например, индустрия компьютерных игр выпускает множество программ, которые должны поддерживаться в течение короткого периода, равного нескольким месяцам или году, и, когда это время истекает, копирование выполняется. старый код из предыдущей игры, где период обслуживания превышен, в кодовую базу новой игры в порядке и может ускорить процесс.
К сожалению, жизненный цикл большинства программ, с которыми мне приходилось сталкиваться в последние годы, сильно отличается от этого. 98% требований или запросов на исправление ошибок, которые поступили ко мне, были запросами на изменениедля существующих программ. И всякий раз, когда вам нужно что-то изменить в существующем программном обеспечении, «управление проектом» или планирование работают лучше всего, когда ваши усилия по тестированию и отладке довольно низки - что не будет иметь место, если вы измените что-то в одном месте, но из-за копирования -Выполненная бизнес-логика, вы легко забываете, что вам нужно изменить дюжину других мест в кодовой базе. И даже если вам удастся найти все эти места, время, чтобы изменить их все (и проверить изменения), вероятно, будет гораздо больше, как если бы у вас было только одно место, чтобы измениться. Таким образом, даже вы могли бы сделать точную оценку изменения, поскольку затраты в десятки раз превышающие необходимые, могут легко вступить в противоречие с бюджетом проекта.
TLDR - всякий раз, когда вы разрабатываете программу, в которой нет необходимости или ответственности за исправление ошибок и обслуживание оригинала или копии, не стесняйтесь копировать. Но если вы, ваша команда или ваша компания несете или можете стать ответственными, примените DRY, когда сможете.
пример
В качестве дополнения позвольте мне объяснить реальный пример того, что означает «исправление ошибок и обслуживание», и как это приводит к непредсказуемости при планировании, особенно внутри одного продукта. Я действительно видел, что такого рода вещи случаются в реальности, вероятно, не со 100 экземплярами, но проблемы могут начаться, даже если у вас есть только один дубликат экземпляра.
Задача: создать 100 различных отчетов для приложения, каждый из которых выглядит очень похоже, некоторые различия в требованиях между отчетами, какая-то другая логика, но в целом не так много различий.
Разработчик, который получает эту задачу, создает первое (допустим, что это занимает 3 дня), после того, как некоторые изменения или незначительные исправления ошибок из-за QA и проверки клиентов завершены, кажется, что все работает нормально. Затем он начал создавать следующий отчет, вставив копию и изменив все, затем следующий, и для каждого нового отчета ему нужно в среднем ~ 1 день. Очень предсказуемо, на первый взгляд ...
Теперь, после того, как 100 отчетов «готовы», программа переходит в реальное производство, и возникают некоторые проблемы, которые были упущены во время QA. Может быть, есть проблемы с производительностью, может быть, отчеты сбои на регулярной основе, может быть, другие вещи не работают, как задумано Теперь, когда был применен принцип СУХОГО, 90% этих проблем можно было бы решить, изменив кодовую базу в одном месте. Но благодаря подходу копирования и вставки, проблема должна решаться 100 раз, а не один раз. И из-за изменений, уже внесенных из одного отчета в другой, разработчик не может быстро скопировать и вставить исправление для первого отчета в другой 99. Он должен просмотреть все 100 отчетов, прочитать их, перевести изменение в измененный сообщите, протестируйте и, возможно, отладьте каждый из них в отдельности. Для ПМ, это начинает становиться действительно трудным - он, конечно, может потратить время на «обычное» исправление ошибки (скажем, 3 часа) и умножить это на 100, но на самом деле, это, скорее всего, неправильная оценка, некоторые из исправлений могут быть легче сделать, чем другие, другие могут быть сложнее. И даже если эта оценка верна, затраты на отладку в 100 раз больше, чем нужно, обойдутся вашей компании в большие деньги.
То же самое произойдет в следующий раз, когда клиент попросит изменить цвет эмблемы своей компании во всех этих отчетах, настроить размер страницы или установить какое-либо другое новое требование, которое аналогичным образом влияет на все отчеты. Таким образом, если это произойдет, вы можете сделать оценку затрат и выставить счет клиенту в 100 раз дороже, чем он должен был заплатить, если код был СУХИМ. Однако попробуйте сделать это несколько раз, и тогда клиент отменит проект, потому что он, вероятно, не захочет оплачивать ваши непомерные затраты на развитие. И, возможно, в этот момент кто-то задаст вопрос, почему это произошло, и покажет пальцем на человека, который принял решение для этого программирования копирования-вставки.
Моя точка зрения такова: когда вы создаете программное обеспечение для других, вы, по крайней мере, в течение короткого периода времени несете ответственность за то, чтобы заставить его работать, исправлять ошибки, адаптировать программу к изменяющимся требованиям и т. Д. детали могут быстро составить гораздо больше, чем изначально планировалось. И особенно, когда весь код, вставленный вами в копию, находится внутри одного продукта, период ответственности за все части одинаков, что весьма отличается от ситуации, когда вы копировали какой-то старый код из мертвого проекта, который больше не является под активным обслуживанием.