Бизнес-аналитика

Артурег ищет бизнес-аналитика.
Цель: отправить куда-то за тридевять земель составлять спеки, по переделке готовой ERP/опердени на новую версию. Далее управлять этим проектом, т.е. миграция в PM.
Ну вопросы миграции бизнес-аналитика в PM мы трогать не будем, но из описания проекта Артурегом мне очень сильно кажется, что они недооценивают задачу.

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

Я верю, что нормальный бизнес-аналитик способен составить оные требований, но опердени для клиентов в ex-USSR - это знатный майндфак, который начинается еще до составления требований. И уж всяко, это не та работа, куда надо искать людей с улицы, не зная толком, что им придется делать.

PS: Впрочем, есть мнение, что я давно сошел с ума от постоянного участия в безумных проектах, где нужно все, сразу и вчера, причем желательно без участия работников, т.к. они заняты другими проектами.
А в нормальных условиях действительно проект можно выполнить силами средних работников, без моноидов в категории эндофункторов, катаморфизмов в SQL, овертаймов, категориальной содомии и прочего трэша, при этом сделав нормальное разделение труда.

Бизнес-логика: Структура данных vs код

plumqqz доставил нам очередную ссылку на ужасы обсуждения БД на хабре. Сама статья еще куда ни шло, за исключением представления constraints как мега-фичи (вроде это основа основ любой БД). В комментариях, само собой, дикий ад, трэш, угар, содомия, коровники, заборы, катаформизм хабракармы и голые бизнес-аналитекши.

Самое ужасное там - это когда структуре данных отказывают в праве считаться частью бизнес-логики, упирая на то, что "надо же абстрагироваться от хранилища".
При этом, даже если добится этого абстрагирования - то все равно структура данных будет в памяти, в виде графа объектов, будет нужен дополнительный код по интеграции этой структуры с тем, что живет в БД, и никуда мы от структуры данных не денемся. А уж про то, можно ли считать констрейнты (в т.ч. и сложные, выражаемые только в виде триггеров) частью типов данных - можно дискутировать вечно. По крайней мере, check и foreign key constraints это точно часть типа данных, в случае FK - это еще и зависимые типы, реализованные в понятном виде. В случае unique constraints - уже сложнее, но по идее, тоже зависимый тип (зависит от данных таблицы, в которой он используется).

Так вот, я считаю, что структура данных для бизнес-логики гораздо более важна, чем собственно код. Если вам скажут, что теперь операция с кодом "777029" не облагается НДС - вам всего лишь нужно добавить веточку в паттерн-матчинг. Структура программы от этого не изменится и коллегам вы билд нахрен не сломаете.
А если окажется, что для того, чтобы узнать, как обрабатывается операция, вам нужно заглянуть в настройки в СУБД - то внезапно, в гламурно-причесанной функционально-иммутабельной функции проверки условий появляется грязная монада IO, провайдеры коннектов к БД, автоматическое управление транзакциями, пул коннектов, кэши и прочая черняга и структура данных (к коей я отношу так же и сигнатуры функций) меняется весьма заметно. Альтернативный вариант - оставить функцию чистой, но добавить к ней еще параметров, передаваемых извне, проверить код коллег, записать в трекер и рассказать, что теперь без передачи в нее оккультного набора параметров функция больше не заработает.