Программирование методом копирования-вставки

Программирование методом копирования-вставки также нередко применяется опытными программистами, имеющими свои библиотеки хорошо протестированных и готовых к использованию сниппетов и общих алгоритмов, приспосабливаемых к конкретным задачам[2].

Вместо создания нескольких изменённых копий обобщённого алгоритма объектно-ориентированный подход предлагает абстрагирование алгоритма в инкапсулированный класс, который может быть использован повторно. Такой класс создаётся гибко, с полной поддержкой наследования и перегрузки, что позволяет вызывающему коду взаимодействовать с одним обобщённым кодом, нежели с несколькими или многими изменёнными[9]. По мере расширения необходимой функциональности, библиотека также увеличивается в размере (с сохранением обратной совместимости). Так, если в оригинальный алгоритм вносят исправление бага, то всё программное обеспечение, использующее этот алгоритм и библиотеку, выигрывает.

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

• Управляется системой контроля версий, поддерживающей ветвление
• Ветви повторно объединяются после завершения разработки

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

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

• Нет необходимости регрессионного тестирования существующего продукта;
• Экономится время, связанное с обеспечением качества;
• Сокращается время выхода на рынок;
• Отсутствует риск внесения новых ошибок в существующий продукт (что могло бы нарушить существующую базу пользователей).

Недостатки:

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

Еще одной альтернативой C&P-подходу является модульный подход:

• Изначально в библиотеки или модули выносится код, который будет общим для обоих продуктов;
• Использование созданных библиотек является основой для разработки нового продукта;
• Если предусматривается существование третьей, четвертой, пятой и т. п. производной версии продукта, то такой подход гораздо сильнее копирования-вставки, поскольку резко сокращает цикл разработки любого дополнительного продукта после второго[10].

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

• Копирование-вставка зачастую приводит к большим по размеру методам;
• Каждый экземпляр создает дубликат кода со всеми проблемами, описанными ранее, но в гораздо большем масштабе. Обычно существуют десятки дубликатов, но возможны и сотни. Исправление ошибки становится очень сложной и дорогостоящей задачей[11];
• В такого рода коде присутствуют вопросы удобочитаемости. Проблемы, связанные с трудностью определения различий между повторениями оказывают прямое влияние на риски и расходы по внесению правок в код;
• Модель процедурного программирования настоятельно не рекомендует прибегать в решении повторяющихся задач к подходу программирования методом копировать-вставить. Предпочтительным решением является создание функции или подпрограммы, которая выполняет один проход через задачу. Такая подпрограмма затем вызывается родительской программой повторно, либо в некоторой форме цикла. Такой код называется «хорошо декомпозированным» и рекомендуется как легко читаемый и более готовый к расширению[12];
• Основная эмпирическая закономерность для такого случая: «не повторяйся». Дэвид Парнас сформулировал это правило так: «Копирование и вставка кода — следствие ошибки проектирования»[13].

Простым примером допустимого применения подхода может быть цикл for, который может выглядеть как for (int i=0; i!=n; ++i) {}. Примером кода, использующего такой цикл может быть:

void foo(int n) {
    for (int i=0; i!=n; ++i) {
    }
}

Код цикла может быть сгенерирован следующим сниппетом (определяя типы и имена переменных):

for ($type $loop_var = 0; $loop_var != $stop; ++$loop_var) {
}

Многие программисты часто используют подход из-за нежелания переписывать строчку, отличающуюся от предыдущей лишь несколькими символами (например, вызов одной функции для двух однотипных объектов, имена которых различаются незначительно). Дублировать предыдущую строку (также при помощи клавиатурных сокращений) оказывается быстрее, чем переписать её заново. Но вероятность допустить ошибку не уменьшается[14], в особенности для последней строки[15].

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

mArray[12] = "a";
mArray[13] = "b";
mArray[14] = "c";
mArray[14] = "d";

Существует исследование[16], направленное на «декриминализацию» программирования методом копировать-вставить — Subtext programming language. Следует отметить, что в этой модели, копипаста — основная модель взаимодействия и, следовательно, не рассматривается как антипаттерн.