Какой хороший, краткий способ объяснить опасности программирования с копированием-вставкой для непрограммистов? [закрыто]

Я ищу хорошую аналогию или метафору, которая могла бы проиллюстрировать проблемы программирования с копированием и вставкой для непрограммистов. Я иногда делаю обзоры кода / системы для потенциальных клиентов, и одной из общих проблем, которые я вижу, являются огромные объемы кода копирования-вставки по всей их кодовой базе. Это то, что я обычно называю в обзорах, и каждый раз мне приходится объяснять, почему это проблема (это особенно сложно для клиентов, которые достаточно хорошо разбираются в программировании, чтобы понять, что повторное использование - это хорошо, но недостаточно, чтобы понять, почему copy-paste не является хорошей формой повторного использования). Очевидно, что я могу (и могу) объяснить проблему с точки зрения обслуживания кода, но было бы неплохо иметь хорошую, краткую аналогию для этой проблемы, которая встречалась бы с непрограммистами. Бонус, если аналогия иллюстрирует, почему поиск и замена не является эффективным решением этой проблемы. Какие-либо предложения?

Просто чтобы уточнить (основываясь на ответе Ярослава ниже) - я не говорю об использовании фрагментов кода здесь; То, что я вижу (очень часто), - это копирование и вставка огромного количества кода или фрагмента кода из десяти строк, чтобы некоторые пользовательские данные (в комплекте с встроенным SQL-запросом) вставлялись в десятки страниц PHP или ASP.NET. Итак, дублируйте код из другого места того же проекта.

Обновление: здесь есть несколько действительно хороших ответов; В комментариях я объяснил, почему я выбрал ответ Скотта Уитлока, но я также очень рекомендую ответ whatsisname, если вы имеете дело с клиентами, которые вообще знакомы с производством.

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

Но, конечно, вы хотите знать, который час, не заходя в эту комнату все время, поэтому вы покупаете еще несколько часов и распределяете их по всему дому. Каждый из этих часов независим. Все они держат свое время. Это означает:

• Когда время меняется из-за перехода на летнее время, вы должны изменить их все
• Даже когда они все настроены, они все немного разные и редко соглашаются совершенно. Со временем они дрейфуют.

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

Программирование копирования-вставки похоже на покупку более независимых часов. Это не масштабируется.

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

Теперь вы не создаете полный набор технических спецификаций и чертежей для каждого отдельного двигателя, не так ли? Нет, вы используете один и тот же двигатель во всех четырех местах. Теперь представьте, если у вас было 4 набора рисунков, и вы должны что-то изменить. Теперь вы должны изменить его на всех четырех чертежах двигателя. Что произойдет, если вы случайно забудете что-то поменять в 4-м движке, потому что вы выходите?

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

А теперь представьте, что NTSB доставит вам неприятности, потому что ваши двигатели случайным образом выбрасывают лопасти турбины и взрываются, летя к югу от Флориды. Теперь какие рисунки двигателя вы смотрите? Все из них, один из них? Откуда ты знаешь, что все четыре одинаковы? Возможно, исправления внесены, но они применяются только к первому движку, потому что парень, который проектировал двигатели, оставил год назад, чтобы играть в регги-группе, и был единственным, кто вспомнил, что четыре движка находятся в отдельных файлах, и парень, который исправил взрывную турбину, был его заменой.

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

Не дублируйте двигатели, просто напишите код, который устанавливает двигатели на крыло.

Вы должны объяснить это с точки зрения совместного использования одного и того же ресурса по сравнению с дублированием одного и того же ресурса.

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

«Эй, смотри, все операции несколько похожи, верно?», Так что ты не против, если я случайно скопирую хирургическую инструкцию для разных процедур от разных хирургов для твоей операции?»

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

В поисках аналогии, сначала мы должны рассмотреть опасность копирования и вставки :

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

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

Абстракция основана на идее создания определений и последующего использования этих определений при исполнении. Каким был бы мир без определений?

• Определения являются ключевой частью юридического языка. Представьте себе контракт, в котором не было основных определений, но каждый раз определялся каждый термин.
• Определения и шаблоны используются в строительстве. Общей проблемой в построении является создание каждого нового разреза на основе последнего, а не одного измерения, выполненного в начале. Это может привести к диким изменениям длины с течением времени.
• Организация компании основана на рефератах и ​​определениях. Что если каждый раз, когда ваша компания должна была расширяться, ей приходилось определять новую роль с нуля? Это не сработает. Так что, если они решат просто выбрать похожую должность и немного изменить ее, чтобы она подходила. Все были бы заперты на месте, потому что было бы невозможно перемещать ресурсы вокруг.

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

Абстракция борется с этим, связывая все ветви вместе в один ствол и выделяя модификации для более мелких ветвей или даже листьев.

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

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

Еще одна аналогия: банкоматы. У вас есть один банкомат, который может обслуживать различные карты и всегда хорошо их обслуживает. Дублирование кода создает разные банкоматы, так что каждый должен будет перейти на другой, а иногда машина даже даст вам BSOD.

Есть замечательная статья о копировании копий от Джеффа http://www.codinghorror.com/blog/2009/04/a-modest-proposal-for-the-copy-and-paste-school-of-code-reuse. HTML

PS Я знаю, что до Гутенберга была печатная машина.

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

1. Каждая строка кода стоит вам денег (написанных или скопированных)
2. Каждый баг стоил вам гораздо больше, чем каждая строка.
3. Каждая строка кода добавляет потенциальные ошибки
4. Дублированный код = дублированные ошибки
5. Дублированные ошибки почти никогда не обнаруживаются в одном и том же цикле тестирования.

Вырезать и вставлять = горящие деньги.

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

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

Это показывает, что разработчик либо ленивый, либо эгоистичный, либо оба. Если это битва, в которой вы сражаетесь в команде на данный момент, в зависимости от вашей позиции в этой команде (командный лидер / jnr dev, snr dev, что угодно) вам необходимо исправить ее, возможно, путем арбитража в вашей организации.

РЕДАКТИРОВАТЬ: В свете комментария ниже, что это код проверки стороннего кода от имени третьей стороны (или, возможно, даже четвертой стороны :)) Есть некоторые полезные вещи, которые я могу добавить, надеюсь.

Во-первых, когда код был создан для третьей стороны, были ли у них какие-либо показатели? Строки кода (LoC), например.

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

В любом случае, вы оцениваете качество кода, ну, скопируйте любую вставку, подпадающую под категорию «Разработчик показал адекватное понимание абстракции и / или дизайна управления потоком программ»:

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

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

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

Кажется разумным?

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

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

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

Есть также проблемы безопасности и целостности кода.

Как показано здесь , можно вставлять вредоносные данные в символы Unicode, которые передаются в буфер обмена.

В зависимости от того, как ваш редактор реагирует на символы Юникода, это может привести к неожиданным изменениям исходного кода, неожиданным выводам компилятора или некоторым вещам, о которых я еще не думал.

Есть несколько разных маршрутов:

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

2. Слепо следуя указаниям - большинство людей, вероятно, имели бы опыт, чтобы добраться до места, где они не были ранее. Некоторые, возможно, использовали MapQuest или Google Maps, чтобы найти место, а затем следовать указанным инструкциям. Были истории, когда люди терялись или просто не находили, где они должны были быть, хотя программное обеспечение давало конкретные инструкции, как туда добраться. Еще одна большая опасность копирования-вставки заключается в том, что это похоже на то, как если бы кто-то просто вручил вам указания, как добраться от А до Б, не давая вам увидеть карту местности, которая может немного усложнить поездку. Если это не кажется сложным, вы можете повысить ставку, попросив человека перейти от А к В в повязке, чтобы ему пришлось полагаться на другие чувства, чтобы определить, в каком направлении они смотрят, и добраться до цели.

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

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

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

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

Модель стоимости CoCoMo.

http://en.wikipedia.org/wiki/COCOMO

Приложенное усилие (E) = a * (KLOC) ** b, где b> 1,0

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

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

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

Есть три основные проблемы с этим:

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

Допустим, у вас есть 5 подружек (вы хитрая собака), и вы хотите отправить всем им сообщение Валентина. Вы вводите первую букву, добавляете ее имя и упоминаете что-то запоминающееся, что вы, ребята, поделились. Затем вы копируете и вставляете письмо четыре раза, каждый раз пропуская экземпляр имени подруги # 1 с помощью функции копирования и вставки, потому что вы сделали опечатку. Теперь 4 из ваших пяти подружек едут в дом подруги № 1.