Чи існує формальна анти-модель для опису сценарію?

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

• Код працює дуже погано.
  
  • Підсистема призначена для генерування файлів вночі. Виконання не турбує вночі.
    • Створена функція для вибору правильного файлу з 100 різних доступних файлів залежно від обраного набору параметрів.
    • Оскільки фізичні файли існують, для створення резервного копіювання цих файлів додається архівна система (Аргументувати немає причин. Ці файли потрібно генерувати на ходу).
    • Ця система не включає файл конфігурації, натомість вона має жорстко закодовану функцію "вибору сервера", яка просто відображає сервер, на якому працює код.
    • Для підтримки та запуску цієї послуги необхідно заплановане завдання.

Це зводиться до однієї проблеми. Оригінальний код працює надто погано, щоб працювати у виробничих умовах.

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

Це "каскадний збій", якщо ви хочете. Початкова проблема призвела до більш поганого коду, більше поганих рішень та непотрібних витрат. Чи існує формальний антидіапазон чи загальний термін для його опису?

Потік лави?

У жаргоні комп’ютерного програмування потік лави - це проблема, при якій комп'ютерний код, записаний в неоптимальних умовах, вводиться у виробництво та додається до того часу, поки він знаходиться в стані розвитку.

З проекту Perl Design Wiki: Потік лави - це "коли код ... з'являється і стає постійним, він стає архітектурною особливістю археологічного різноманіття. Речі будуються на всій структурі без сумнівів і без надії змінити те, що знаходиться під ними. існуючий код розглядається як історична цікавість ».

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

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

Потік лави вважається антитілом, явищем, що часто зустрічається, що призводить до поганого дизайну.

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

Проблема полягає в тому, що, щоб бути корисним анти-шаблоном, необхідно описати якусь загальну проблему та як цього можна уникнути. У цьому випадку я думаю, що це було б пошук обходу для коду, який працює погано, коли ви могли просто зробити його краще.

Проблема з цим як антидіаграфом, IMHO, полягає в тому, що знання про нього, здається, малоймовірне. Хто б це робив, мабуть, уже розумів, що було б непогано знати, як змусити його працювати краще, тому вони, мабуть, не знали, як це зробити. Тож почувши про загальну ситуацію як антидіаграму, насправді не допомогло б.

Що стосується загального терміну для його опису, "каскадний збій", як ви запропонували, працює досить добре. Термін, який мені подобається для некваліфікованих людей, які від'їжджають на місію, яка в першу чергу не мала сенсу, - це полювання на снайпер , але це здається занадто суворим для цієї ситуації. (Але я все-таки дещо безоплатно перекинув посилання, оскільки це найкраще зображення приреченого підприємства, якого я знаю).

Невідомо, чи це допомагає, але автоматизація офісу часто є окремим випадком:

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

На відміну від архівування того, що ви описуєте, на жаль, найкраща практика в деяких випадках.

Посилання: http://support.microsoft.com/kb/257757