(Большое спасибо одногруппнику Петру за разговор, который заставил меня полностью переосмыслить прочитанное и выбросить прошлый вариант этого текста.)
Довольно несложно понять, почему книга даётся в качестве “входной” литературы к курсу системного мышления (на самом деле — даже нижележащего по стеку курса онтологики и коммуникации):
- Автор работает в какой-то своей, достаточно уникальной терминологии. В частности, его истолкование ключевого термина Object-Oriented достаточно далеко как от “типового” понимания в современной индустрии, так и от оригинального значения этого термина, введённого Аланом Кеем (который описывал этим системы из акторов и шин передачи сообщений, см. например http://xahlee.info/comp/Alan_Kay_on_object_oriented_programing.html). Более того, в предисловии ко второму изданию автор честно признаётся, что изначально использовал слово “парадигма” в значении “онтология” — но ко второму изданию переименовал всё обратно (а на самом деле — не всё, и “уши” оригинальных именований проступают в тексте тут и там). Разбираться с этой авторской терминологией было не то что бы просто (и привело меня в итоге к крупному мыслительному сбою, о котором см. ниже) — но это однозначно тренирует “терминологический агностицизм” («Термины — одновременно не важны и важны»), на котором строится весь курс.
- Ещё более релевантен сам метод ре-инжиниринга — он очень созвучен принципам мышления (в том числе коллективного, “договаривания”) через движение туда-сюда по шкале конкретного⋄абстрактного мышления: мы переходим от более конкретного (кода) к абстрактному описанию программной системы, там происходит какая-то магия, и потом обновлённое абстрактное описание приземляем обратно в обновлённый код. А какая-то магия — это обратное движение по (ортогональному к программистскому) измерению абстрактности⋄конкретности применительно к конечному бизнесу: мы пытаемся “приземлить” абстрактное описание на конкретные бизнес-процессы, находим в ходе этого несоответствия, договариваемся об их исправлении — и от конкретного, уже общего для всех участников, понимания бизнес-системы переходим обратно на уровень более абстрактных описаний (в этот раз оперируя уже предлагаемой автором абстракцией бизнес-объектов).
- Очень большое внимание уделяется авторскому изложению принципов 4D-экстенсионализма. Не могу сказать, чтобы это как-то оказалось именно мне полезным: моё “четырёхмерное воображение” по большей части сформировалось ещё до начала занятий, в основном через чтение/просмотр научной фантастики про путешествия во времени — и представления курса очень легко легли на эту базу. Так что конкретно мне настолько детальные рассуждения в этой части BORO показались несколько затянутыми.
При этом не могу не пожаловаться, что эта местами-затянутость — характерная черта всего построения книги. Подобный “исторический” подход к построению учебников критиковал ещё Фейнман — нет необходимости подолгу рассказывать в учебнике географии про плоскую (а потом — про имеющую форму сундука) Землю, эффективное обучение предполагает как можно более скорый переход к SotA-моделям. Точно так же расточительно тратить сто с лишним страниц на Entity, Substance и Logical Paradigm, только ради того чтобы потом на их недостатках обосновать необходимость новой, Объектной, прадигмы.
Более того, тратить слишком много ученического внимания на разбирательство с устаревшими (но более простыми и интуитивными — это SotA частенько контр-интуитивен!) кажется вообще вредным: теорию потом отвергнем, но наработанные в мозгу интуиции-то от этого никуда не денутся! Кажется, это и стало вторым компонентом моей ментальной ошибки.
Неадекватные ментальные пред-установки + авторская терминология + долгая подводка к основным тезисам ⇒ ментальная ловушка
Разумеется, интеллектуально-нечестно винить кого-то, кроме себя самого в том, что я попал в ментальную ловушку, ожидая от его книги не того, чем она оказалась. Тем не менее, мне кажется важным подробно разобрать эту ошибку, и откуда у неё “растут ноги”, чтобы больше не попадать впросак по крайней мере таким же точно образом.
Анатолий Игоревич книгу порекомендовал “для айтишников”. Почему-то я после этого ждал, что книга будет описывать какой-нибудь неконвенциональный, но SotA подход, который инженеры обычно упускают из-за слабой системномыслительской подготовки — похожим образом, например, программисты упускают Event Sourcing из-за слабости в функциональном программировании.
Читая книгу с этой установкой в голове, и следуя заветам Школы в том, что терминология всегда авторская и подлежит ре-интерпретации — я очень крупно в этой ре-интерпретации ошибся. Я забыл сделать скидку на то, что книга была издана в 1998 году, и борется с заблуждениями тогдашних общепринятых практик, а не общепринятых практик 2021 года! И когда Партридж говорит что “все пишут код через entity-attribute подход, а я сейчас покажу как можно изящнее” — это “все пишут” не соотносится вообще никак с тем, как эти все пишут код последние 15 лет, пока я это наблюдаю.
Да, я посчитал entity-attribute подход Партриджа — описанием практик современного мне (и несколько устаревающего) объектно-ориентированного программирования! И даже успел подумать что “ого, это что же, автор ещё в 1998 году увидел нишу для ECS-систем, NoSQL-решений и прочих онтологических троек в графовых БД?!”
Интерпретировать текст с такого ракурса было довольно сложно. Недостаточно сложно, чтобы сразу заметить ошибку — ведь книга начинается с описания не-объектных подходов (а про объектный по началу говорит очень мало и уклончиво), да ещё и избегает приводить примеры из программистских реалий. Но достаточно сложно, чтобы как следует прокачать у себя ментальный мускул терминологической ре-интерпретации, только ради того чтобы потом хлопнуть себя по лбу и воскликнуть “блин, так он под объектно-ориентированным бизнес-моделированием и правда классы из Java имеет в виду!”
Это был достаточно болезненный — но, надеюсь, полезный опыт. А собственно навык бизнес-моделирования я пока поставлю ментально куда-нибудь на дальнюю полку: в моей нынешней индустрии эти практики занимают от силы 10% времени, и гораздо важнее, скажем, практики, нацеленные на максимально безошибочный перенос в код алгоритма, изложенного и доказанного в научной статье. (Но если наше решение будет успешным — больше никому не придётся этими алгоритмами заниматься, и бизнес-моделирование вернётся в фокус инженерных практик. Но это уже совсем другая история.)