Антипаттерн “Cut-and-Paste” (aka Копипаст).

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

Сегодня будем рассматривать антипаттерн под названием “Cut-and-Paste” ( копипаст если по-русски 😉 ).

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

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

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

Антипаттерн “Cut-and-paste” определяется наличием похожих кусков кода разбросанных по всей программе. Иногда, причиной такого поведения программистов является то, что над некоторыми проектами работают несколько программистов и новички в проекте, стараются следовать примерам более опытных программистов.

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

Особенности антипаттерна “Cut-and-Paste”:

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

Среди самых популярных причин появления такого кода находятся:

  • Программисты, не знакомые с системой, новой технологией или инструментами, берут готовый пример и переделывают его под свои нужды.
  • Организации, разрабатывающие ПО, не являются сторонниками повторно используемых компонентов, а скорость разработки программ способом Cut-and-Paste перекрывают все остальное.

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

Удачи.





Читайте также:



8 Ответов на “Антипаттерн “Cut-and-Paste” (aka Копипаст).”

  1. Пожалуй вернее будет называть его Copy-and-Paste, а то у вас катопаст получается =)

  2. cryptus

    Странно вообще. На английском используется выражение именно Cut-and-Paste (в лингво глянуть можно) для того, что мы называем копипаст. Поэтому я оба варианта использовал в статье. :)

  3. [ссылка] - здесь ничего общего с программированием нет.

    [ссылка]
    [ссылка]

    Да и посмотрите на вашу картинку :)

  4. cryptus

    Cut-and-Paste в вики.
    [ссылка]

    Вот еще перевод который я имел в виду -
    [ссылка]

    Иии вот еще
    [ссылка]
    :)

  5. Первые две ссылки не имеют отношения к программингу ) Вы упрямы :)

    Рассудите сами логически, cut это вырезать, если же код вырезается то он не дублируется и ваши “особенности” становятся не актуальными.

    Скорее всего cut and paste также употребляется, иногда, но слово копипаст появилось определенно от copy paste

  6. cryptus

    Да это понятно, что перевод не точный я дал. Я просто к тому, что под Cut-and-Paste в последней например ссылке которую я дал, подразумевается операция знакомая нам как перенос кода через копирование - “копипаст”. Хотя, очевидно, я согласен, что Cut-and-Paste - это вырезать из одного места и перенести в другое и непонятно, почему этот антипаттерн иногда называют Cut-and-Paste в английской литературе. Ясно, ведь, что при программировании такая операция не используется - а используется именно Copy-paste. :)

  7. Фима

    Кстати, а википедию тоже люди писали, причём вполне возможно, с ошибками.

  8. Еще одна причина возникновения копи-паста это уделение недостаточно времени для проработки структуры приложения или недостаток начальной информации.
    Ну и конечно же неорганизованость в коллективе и реактивная разработка.
    Лечение в дальновидности - изначально предусматривать возможность удобного рефакторинга кода.

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


© Copyright. . I-Novice. All Rights Reserved. Terms | Site Map