Это понедельник.
Вы сидите с каким-то бизнес-аналитиком.
Он описывает вам следующую функцию, которую он хотел бы продать/иметь.
Он часто использует слово «рабочий процесс».
Архитектор, хорошо знакомый с этими обменами, небрежно предлагает, что «мы должны реализовать очень простой механизм процессов».
Аналитик полностью согласен.
В этот момент ты пиздец.
Песня сирены-метафоры
Видите ли, проблема в том, что люди так сильно любят обещания, данные «рабочими процессами». Они ничего не могут с этим поделать.
Они видят работу, которую нужно сделать, работу, которую можно легко разделить на более мелкие части, части, которые вы можете легко нарисовать на доске с помощью простых прямоугольников и стрелок. Они повсюду видят объектно-ориентированные метафоры. Вот класс «Шаг». Вот это "Триггер"! условие" ! Это так наглядно! Приложение, кажется, проектирует себя!
Но все имеет свою цену; и большинство людей действительно не понимают, что они должны платить.
Разработка начинается. Достаточно скоро приходит осознание того, что данные должны быть разделены между шагами. Так начинается неизбежное и трагическое введение класса «Контекст». Он должен быть универсальным, верно? Таким образом, даже если вы используете статически типизированный «предпринимательский» язык, в него добавляется карта нетипизированных метаданных. Не беспокойтесь, это должно покрыть все потребности.
Затем неизменно приходит идея собрать рабочий поток во время выполнения в каком-то внешнем формализме, возможно, XML, JSON или YAML, в зависимости от вкусов.
Через несколько дней полный набор суффиксов шаблонов проектирования был исчерпан. Архитектор показывает очень плотную диаграмму классов в своей презентации удовлетворенному, но блаженно невежественному руководству.
Что вы наделали?
Поздравляем!
Вы только что построили вычислительную модель поверх вычислительной модели.
Очень дерьмовая, неформальная, неполная, недокументированная и плохо протестированная модель вычислений.
О, но еще слишком рано, чтобы признать это. Сначала вам нужно вытерпеть бесконечный цикл агонии.
Шаги искупления
Продукт, наконец, попадает в производство, и достаточно скоро начинают появляться первые билеты.
Вы запускаете отладчик. Вы попадаете в функцию, пытающуюся разобраться в невообразимой мешанине нетипизированных данных и неверных предположениях о текущем состоянии выполнения.
Ваш разум блуждает. Эту функциональность было бы так просто реализовать… с помощью всего лишь кода. Вы знаете, просто вызывая функции API, бросая свои «если» и «возврат» туда и сюда.
«Недостаточно перспективно», — вы могли бы услышать, если бы осмелились это предположить.
Итак, вы предлагаете внести некоторые изменения в рабочий процесс, перетасовывая некоторые этапы. Это просто вопрос изменения XML, верно? Неправильный ! Шаги имеют неявно жестко закодированные предварительные условия, и вам также нужно изменить то, что они делают. Ваш менеджер слышит, что вам нужно выпустить новую версию, и кричит на вас.
Проходят месяцы.
То, что было набором изолированных шагов с ограниченным, сфокусированным объемом, теперь стало безбожными башнями кода, потому что так было как-то легче управлять.
Лучшие кодеры давно ушли. Архитектор тоже.
По крайней мере, можно сказать, что «урок усвоен». Простите, у этой истории нет счастливого конца. Скорее всего, вы испытали этот ужас несколько раз в своей жизни.
Потому что ты знаешь. Это просто рабочий процесс. Но в следующий раз мы просто воспользуемся подходящим коммерческим BPM-движком. Я слышал, что крупные компании используют их.
