Дробовиковая хирургия

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

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

Сообщество рефакторингов обычно не одобряет эту практику как прямое нарушение принципа абстракции , также известного как правило «Один раз и только один раз» — в конечном итоге любое изменение новой функциональности может потребовать масштабных изменений. Кроме того, любая потенциальная программная ошибка в этой новой функции будет многократно воспроизведена, что может сделать исправление ошибок особенно трудным и утомительным. Даже при отсутствии скопированного кода реализации гарантированно будут очень похожи и столь же подвержены изменению требований или исправлению ошибок. Эта форма разработки программного обеспечения имеет тенденцию отдавать предпочтение краткосрочным улучшениям (в виде дополнительных функций) за счет долгосрочной удобства сопровождения и стабильности.

Пример

Каноническим примером этой практики является ведение журнала , при котором код пролога обычно добавляется ко многим функциям одновременно, например:

void Func() {
  ...
}

void Func2() {
  ...
}

...

void FuncN() {
  ...
}

Может быть преобразовано в:

void Func() {
  printf("Entering Func\n");
  ...
}

void Func2() {
  printf("Entering Func2\n");
  ...
}

...

void FuncN() {
  printf("Entering FuncN\n");
  ...
}

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

Последствия операции с дробовиком

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

Обычно ожидается некоторая комбинация следующего:

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

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

смягчение последствий

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

См. также

• Отладка дробовика
• Технический долг
• Вязкость , измерение устойчивости к изменениям для оформления обозначений .