Существует ли формальный анти-паттерн для описания сценария?

Некоторый код написан для создания электронных таблиц Excel (Office Interop).

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

Это сводится к одной проблеме. Исходный код работает слишком плохо, чтобы работать в производственной среде.

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

Это «каскадный сбой», если хотите. Первоначальная проблема привела к большему количеству плохого кода, большему количеству плохих решений и ненужным накладным расходам. Существует ли формальный анти-паттерн или общий термин для его описания?

Поток лавы?

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

Из Perl Design Wiki: Lava Flow - это «когда код ... извергается и становится постоянным, он становится архитектурной особенностью археологического разнообразия. Вещи строятся на структуре без вопросов и без надежды изменить то, что находится под ними. существующий кодекс рассматривается как историческое любопытство ".

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

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

Поток лавы считается анти-паттерном, часто встречающимся явлением, ведущим к плохому дизайну.

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

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

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

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

Не уверен, поможет ли это, но автоматизация офиса часто является особым случаем:

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

Помимо архивирования того, что вы описываете, к сожалению, в некоторых случаях рекомендуется.

Ссылка: http://support.microsoft.com/kb/257757