Проблемы с 1С возникают всегда и у всех. Я всегда топил за то, чтобы программист решал эти проблемы с помощью отладки – наливаешь чайку, устраиваешься поудобнее, и пошёл разбираться. Потому что «в наше время» существовало лишь два способа решения проблем: метод тыка и отладка – спросить-то не у кого было. Соответственно, кто решал методом тыка, назывался «консультант» или «аналитик», а владеющий отладкой гордо именовался «программист 1С».
Однако, со временем стало появляться всё больше задач, которые отладкой не решаются, по разным причинам. Во-первых, у клиента может быть выключена отладка на сервере, а решать задачу надо быстро, ещё и прав на перезапуск службы нет, а админ греет старые косточки на море. Во-вторых, ситуация может не воспроизводиться – оно уже случилось, и надо понять, почему. В-третьих, господа из одной замечательной компании любят включать в конфигурацию запароленные модули, или не включать исходный текст вообще. В-четвёртых, дело явно не в коде типовой конфигурации – у других клиентов прекрасно работает, а конфигурация на замке. В-пятых, речь работе какого-нибудь бешено долгого процесса – устанешь ждать, пока дойдёт до точки останова. Ну и т.д.
Сначала я расстраивался из-за того, что нельзя применить отладку. Злился, но решал задачи без неё. Потом появился интерес – это ведь что-то типа квеста, игра такая, с искусственными ограничениями. Чем дальше, тем больше меня увлекали такие задачи. Я их даже, можно сказать, полюбил.
А тут пришлось учить новых молодых программистов. Соответственно, надо как-то систематизировать подходы к решению задач. Сначала я придумал термин «детективные задачи», но не мог толком объяснить, что это такое и какие методы следует изучить и применять. Но постепенно инструментарий более или менее сложился – его и хочу изложить.
А главное, появилось чёткое разделение между отладкой и детективом. Отладка – это поиск ошибки с помощью отладчика для воспроизводимой ситуации. Детектив – это поиск проблемы без отладки.
Прокачка навыка
Сначала главное скажу, чтобы потом не возвращаться. Навык решения детективных задач качается только личной практикой. Если решение найдено в интернете – личный навык не прокачивается. Точнее, прокачивается навык поиска информации в интернете.
Я не пытаюсь сказать, что искать ответы в интернете – плохо. Оценка зависит от цели. Если цель – решить задачу, то гуглить – нормально. Если цель – решить задачу и прокачаться, то интернет всё испортит.
Разница примерно такая же, как пройти квест самому или с помощью проходилки.
Исключение
Единственное исключение – партнёрская конференция 1С. Если проблема возникает в типовой конфигурации, то первое, с чего стоит начать – глянуть там.
Если повезёт, то вы не найдёте ответа на свой вопрос. Но найдёте смежные темы, обрывки информации, которые помогут лучше понять контекст происходящего. Партнёрская конференция в этом смысле отличается от остального интернета двумя пунктами: там сидят разработчики из 1С и там почти у каждого написаны ФИО и место работы.
Если же вы нашли прям ответ на свой вопрос, то что ж… Детектива не будет. Зато клиенту быстро поможете.
Отладочное расширение
Итак, у клиента выключена отладка на сервере, а вам кровь из носу надо понять, что там делает серверная процедура. Добавляем расширение, тащим туда эту процедуру и модифицируем – в нужных местах дописываем код, который сообщит вам значения нужных переменных. Просто, как топор.
Но не всегда достаточно возможностей метода Сообщить – данные могут быть сильно страшные. Тут нужен временный логгер.
Временный логгер
Принцип примерно тот же, что у отладочного расширения, только данные мы не сообщаем, а куда-нибудь складываем, чтобы потом на них спокойно посмотреть.
Самое первое место для складывания – журнал регистрации. Вместо Сообщить пишем ЗаписьЖурналаРегистрации, придумываем своё имя события, чтобы быстро найти потом, и засовываем туда всё, что плохо лежит.
Этот же метод можно использовать для отладки проблемы, если не известен способ воспроизведения, а решение может подождать. Пишем в расширении код, который при наступлении ошибки делает запись в журнал регистрации, с максимальным сохранением контекста – кто, когда, откуда и что там вытворяет.
Но журнал регистрации тоже не для всего подходит – например, туда нельзя положить таблицу значений. Поэтому, если время позволяет, можно сделать настоящий временный логгер – что-нибудь типа регистра сведений, в котором будет такая прекрасная вещь, как ХранилищеЗначения. Я обычно создаю регистр со структурой, максимально идентичной журналу регистрации, с добавлением ресурса типа ХЗ – в него уже можно засунуть всё, что душе угодно.
Да, и такой регистр сведений потом проще смотреть – можно написать к нему запрос. И он не будет так тормозить при просмотре, как журнал регистрации. И чистить его проще. И удалить не жалко.
Найди 10 отличий
Бывают ситуации, когда код настолько большой и бешеный, что даже связываться страшно. Но есть чёткое понимание, какой, например, документ работает криво. Но ни фига не понятно, почему именно он.
Визуально он вроде не сильно отличается от остальных – ни пользователь, ни вы разницы не видите. А запрос увидит, потому что разработчики сейчас очень любят скрытые реквизиты, которые адекватно могут заполниться только при правильной ручной работе. Любая обработка программного создания или изменения документов, не понимающая логики разработчиков, может создать проблему.
Итак, просто пишем простенький запрос, который выводит все (до единого) реквизиты документа и/или его табличных частей. В запросе делаем отбор по ссылке, чтобы можно было передать произвольное их количество. И передаём туда как минимум две ссылки – плохую и хорошую. Потом бежим глазками и смотрим, в чём разница.
Да, тут можно и без запроса обойтись – если воспользоваться универсальным отчётом, который есть в современных конфигурациях. Он позволяет смотреть документы, справочники, регистры и т.д.
Метод исключения
Простой метод, из области здравого смысла. Если конфигурация на замке – идём смотреть расширения. Если расширения есть, и названия у них не похожи на заплаты от 1С – отключаем по одному. Разумеется, с соблюдением мер предосторожности, чтобы пользователям жизнь не испортить.
Если после отключения какого-либо расширения проблема ушла – прекрасно, можно вернуть всё как было и использовать метод половинного деления.
Метод половинного деления
Вообще, это численный метод решения уравнений. Но заложенный в нём принцип настолько прост и эффективен, что его можно применять во множестве жизненных ситуаций.
Банальнейший пример – вам надо найти расхождения в двух регистрах. Вы знаете, что на сегодня остатки расходятся. Но не знаете, когда это расхождение возникло – этот момент вам и надо найти.
Делим весь отрезок времени пополам. Например, если учёт ведётся с 2011 года, а сейчас – 2021 г., то будут две половинки лет по 5-6. Смотрим расхождения на конец каждой половинки, и быстро понимаем, что на конец 2016 г. расхождений не было – значит, надо искать во второй половинке.
Вторую половинку снова делим пополам. Если расхождение в первой – работаем с ней. И т.д., итерационно. Сколько тут получится итераций? Где-то 10-12 – столько раз надо сформировать отчёт.
Аналогично можно делить всё, что плохо лежит. Например, в нашем «гадком» расширении так можно аккуратно комментировать половину кода, или код половины объектов, и таким образом быстро сужать место поиска.
Допрос
Как в детективах без допроса-то? Иногда одного этого достаточно. Правда, это не всегда возможно, и не каждому нравится с людьми разговаривать – тут уж сами решайте.
При допросе важно задавать вопросы максимально разнообразно. Пусть расскажут: о проблеме, истории её появления, как воспроизвести, были ли обновления, что происходило за несколько дней до появления проблемы, менялся ли персонал, переезжали ли на новый сервер, меняли ли компьютер, вырубалось ли электричество, меняли ли настройки, пусть покажут последовательность своих действий и т.д.
Допрос можно и нужно проводить итерационно. В том числе, как в настоящих детективах – задавать одни и те же вопросы в разное время, иногда меняя формулировки. Забавно наблюдать, насколько могут отличаться ответы.
В основном же допрос проблему не решает, а позволяет максимально восстановить контекст проблемы и цепь событий. Но люди не всё знают, их показания нужно дополнить данными системы.
Анализ событий
Идём туда, где 1С хранит историю событий – в журнал регистрации и версионирование. Что там смотреть? Что-то связанное с проблемой. Принципиально таких связей две: ссылка и время.
Связь по ссылке понятна – смотрим, что происходило с конкретным документом или документами, связанными с проблемным. Как вариант, можно поиск ссылок сделать – бывает полезно, т.к. прикладные «искалки», вроде структуры подчинённости или связанных документов показывают далеко не всё.
Вторая связь: время. Как в детективах: «что вы делали 5-го числа с 11:00 до 13:00?». Идём в журнал регистрации и смотрим, кто и что делал в указанный промежуток. Особенно пристально смотрим на события, не связанные со стандартной записью данных. Ищем обновления конфигурации БД, долбёж в/из каких-нибудь сервисов, обмены, массовые проведения, подключение/отключение 1Сных сервисов и т.д. Обычно, когда листаешь журнал, что-то обязательно бросится в глаза – какое-то отклонение.
Например, однажды клиент сказал, что «слетело» закрытие месяца в ЕРП с октября. В журнале регистрации нашли, когда сделана запись в журнал заданий закрытия. Фильтранули по периоду, увидели примечательное событие: местный программист вбил логин/пароль интернет-поддержки. Как это могло повлиять?
А легко, это ж ЕРП. Она побежала грузить курсы валют, как раз с октября. Появление курсов спровоцировало необходимость пересчёта курсовых разниц. Ну, дальше понятно.
Сброс
Универсальный метод – вернуть проблемный объект к исходному состоянию. Нужно это для понимания – дело в коде/архитектуре/данных или в каких-то бешеных настройках. Можно сказать, что это – одноитерационная версия метода половинного деления.
Например, если проблема в отчёте – сбрасываем настройки к стандартным. Конкретно в отчётах, особенно если они внешние, надо ещё респаун делать – создать руками внешний отчёт, туда перекинуть всё из проблемного отчёта, и проверить. 1С наворотила вокруг отчётов столько коряво работающего обвеса, что разобраться в нём под силу только избранным. Респаун же влияние обвеса тупо исключает.
В формах – аналогично, надо вернуться к стандартной настройке. Не часто, но бывает: пользователь говорит, что форма списка/выбора сильно тормозит. Если тормозит только у него, то тут и к бабке не ходи – сделал себе группировку дин.списка. В отладке при этом вообще ничего не увидишь. Но будет симптом – бешеное количество обращений к серверу.
Иногда можно в качестве сброса накатить типовую конфигурацию того же релиза.
Ну и кеш, разумеется. Куда без него.
Методы тыка
Пожалуй, стоит и этот метод включить. В некоторых случаях, вроде запароленных модулей или отсутствия кода, это чуть ли не единственный метод решения.
Тут важно что: надо не просто тыкать. Надо тыкать по-разному. Цель тыка – понять алгоритм, не видя алгоритма. Меняйте цифры, наполнение табличных частей, даты, режим проведения, текущего пользователя, настройки и т.д. Тогда что-то станет понятно. Или, хотя бы, сузите контекст воспроизведения.
Воспроизведение на типовой
Иногда помогает. Берём демо-базу той же версии, и ручками пробуем воспроизвести проблемную ситуацию. Получается тот же метод половинного деления. Если ситуация воспроизводится, то задача перестаёт быть детективной, и дальше решается отладкой. Если не воспроизводится, то мы понимаем - дело в данных клиента или доработках. Ну или мы криво воспроизвели, но тут уж ничего не поделаешь.
Интуиция
Все эти методы нужны ровно для одного: развить интуицию. Когда человек решил огромное количество детективных задач, он уже справляется интуитивно. Или тыкает пальцем в небо и попадает прямо в решение, или, как минимум, может максимально сузить контекст поиска и точно определить метод, которым надо воспользоваться.
Ничем, кроме личного опыта, интуицию не разовьёшь. Поэтому возвращаюсь к исходной рекомендации: решайте детективные задачи своим умом, не пользуйтесь интернетом.
Не всегда, не все задачи, но какой-то баланс между быстрым результатом и личной прокачкой соблюдать надо.
