← На главную

Работа с крупными типовыми или сильно кастомизированными конфигурациями часто подкидывает задачи, в которых поиск одной-единственной строки кода превращается в многочасовое приключение. Ситуация, когда реквизит формы заполняется «непонятно где» при открытии, знакома каждому разработчику. Пролистывание тысяч строк кода с помощью клавиши F11 — занятие неблагодарное и крайне неэффективное. В этой статье мы разберем комплексный подход к отладке, который позволит вам находить причины изменения данных за считанные минуты.

Метод деления пополам (дихотомия)

Рассмотрим ситуацию, когда в процедурах ПриСозданииНаСервере или ПриОткрытии выполняется огромный объем кода. Вместо того чтобы идти по шагам с самого начала, мы применим метод отсечения. Разберем этот алгоритм по шагам:

1. Установим точку останова в самом начале процесса (например, в первой строке ПриСозданииНаСервере) и в самом конце.
2. Проверим значение реквизита в начале. Допустим, оно пустое.
3. Перейдем к конечной точке. Если значение изменилось — значит, искомый код находится между этими точками.
4. Теперь поставим точку останова ровно посередине этого блока кода.
5. Перезапустим отладку. Если в середине блока значение уже заполнено — ищем в первой половине. Если еще нет — во второй.

Повторяя эти действия, мы очень быстро сузим диапазон поиска до нескольких строк. Этот метод гораздо надежнее, чем простое чтение кода глазами, так как вы опираетесь на фактическое состояние данных в памяти 1С.

Использование условных точек останова

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

Для настройки такой точки выполните следующие действия:

1. Установите обычную точку останова (клавиша F9).
2. Нажмите на нее правой кнопкой мыши и выберите пункт «Условие».
3. В появившемся окне введите логическое выражение.

Например, если мы ищем, где Объект.Сумма становится больше нуля, условие будет выглядеть так:

Объект.Сумма > 0

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

Отслеживание через Табло (Watch)

Выясним, как использовать Табло для мониторинга. Вы можете добавить интересующий вас реквизит в окно табло и просто нажимать F10 (переход через процедуру). Как только значение в строке табло изменится (оно подсветится синим или красным цветом в зависимости от версии платформы), вы поймете, что последняя выполненная строка и была причиной изменений.

Поиск по контексту и косвенные присваивания

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

• Использование универсальных механизмов: Часто применяется процедура ЗаполнитьЗначенияСвойств(). В этом случае имя вашего реквизита в коде может вообще не фигурировать как левая часть выражения присваивания.
• Обращение через квадратные скобки: Данные могут записываться как ЭтотОбъект["ИмяРеквизита"] = Значение.
• Мутабельные значения: Если реквизит является ссылкой на объект или структуру, его свойства могут меняться внутри подчиненных процедур.

В таких ситуациях мы рекомендуем использовать глобальный поиск (Ctrl+Shift+F) не по точному совпадению, а по части имени метаданных, а также проверять все вызовы ЗаполнитьЗначенияСвойств, где ваша форма или объект выступают в роли приемника.

Особенности отладки динамических списков

Рассмотрим ситуацию, описанную в сообщении №19: данные в форме есть, но запрос, скопированный из ДинамическийСписок, в консоли запросов ничего не возвращает. Это классическая проблема окружения.

Чтобы понять, как заполняется ДинамическийСписок, проанализируем следующие объекты:

1. Параметры запроса: Проверьте в отладчике коллекцию Список.Параметры. Часто там программно устанавливаются границы периодов или ссылки на связанные объекты.
2. Настройки компоновки: Зайдите в Список.КомпоновщикНастроек.Настройки.Отбор. Там могут быть установлены фиксированные отборы, которые не видны в пользовательском интерфейсе, но жестко ограничивают выборку.
3. Основная таблица: Если у списка указана ОсновнаяТаблица, платформа сама накладывает ограничения прав доступа (RLS). Попробуйте выполнить запрос под полными правами, чтобы исключить влияние безопасности.

Замер производительности как инструмент навигации

Когда кода слишком много, мы можем использовать «Замер производительности». Это «хитрый» способ увидеть карту выполненного кода:

1. Включите замер (меню Отладка — Замер производительности).
2. Выполните действие (например, откройте форму).
3. Выключите замер.

В открывшемся окне вы увидите список всех процедур и функций, которые были реально вызваны. Отсортировав их по количеству вызовов, вы сможете быстро понять, в какие модули «заходила» программа, и исключить из анализа те ветки кода, которые вообще не исполнялись.

Работа с фоновыми заданиями

Проанализируем проблему отладки фоновых заданий, упомянутую в теме. Если при каждом останове у вас открываются новые окна конфигуратора, это признак включенного автоматического подключения.

Совет: используйте HTTP-отладку (доступна в современных версиях платформы 8.3). Она работает стабильнее. Если же вам нужно поймать конкретное фоновое задание, установите галочку «Фоновые задания» в настройках подключения, дождитесь остановки в нужном месте и сразу снимите её, чтобы не плодить лишние сессии отладки.

Подводя итог, можно сказать, что эффективная отладка — это не скорость нажатия на клавиши, а правильное сочетание инструментов: от дихотомии и условных точек до анализа компоновщика настроек и замера производительности. Используя эти методы в комплексе, вы сократите время поиска ошибки с нескольких часов до нескольких минут.