Я - опытный проктолог

fixin — 15.04.2019 Как часто у меня в работе бывает такое, что начинаешь решать какую-то сложную проблему, особенно в навороченных типовых конфигурациях и кажется, что всё, приплыли - сушите вёсла - задача не решается.
Так и в четверг 11 апреля у меня возник ступор. Я отлаживал сложный процесс, каждый перезапуск занимал 5 минут и никак не мог уловить причину геморроя. В конце дня задачу так и не решил, но, умудренный опытом, забил и решил, что "утро вечера мудренее".

И что вы думаете, утром поставил точку останова в момент изменения статуса объекта и отловил проблему.

Но то, что вскрылось, оказалось кошмарным. Типовую конфигурацию дорабатывали и внесли такое изменение, что просто непонятно, как оно могло работать.







Типовой механизм в начале строил дерево узлов. Пользователи могли выполнять отдельные узлы, когда до узла доходила очередь. Речь о согласованиях пользователями договоров.

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

И разработчики тупо вставили команду выполнения узла, но (epic fail, о Гоги) эту команду они вставили в момент создания дерева. Т.е. команда выполнения вызывалась, когда дерево еще не было полностью нарисовано. Из-за этого согласование вообще могло завершиться, если выполнялись автоматом первые узлы. Поэтому потом разработчиком пришлось насовать кучу затычек и контролей от быстрого завершения согласования. И они тоже не работали как надо.

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

В конце отрисовки дерева находил все такие узлы и выполнял.

И все заработало как надо, без затычек. Моё вмешательство оказалось минимальным, хирургическим.

На разбирательство с проблемой я затратил 2 рабочих дня - 16 часов. На решение проблемы - 3 часа.

Так что я реально Гений 1С и умею находить "корень зла".

Оставить комментарий

Популярные посты:

• Ранее
• Архив