Ревью кода 1С · 18 мин
От поиска к проверке изменения: как LEM помогает агенту работать с кодом 1С
Поиск и доказательства, временные правки, типы BSL, кандидаты БСП и проверка изменений.
Найти похожую процедуру — только начало задачи. Агенту ещё нужно понять, относится ли находка к нужной версии проекта, какие вызовы действительно связаны с ней, что изменится в предлагаемой правке и какие проверки остаются за человеком или работающей 1С. LEM собирает эти этапы в один проверяемый маршрут.
Разные поиски отвечают на разные вопросы
Точный текстовый поиск полезен, когда известно имя метода, объекта или сообщение ошибки. Смысловой поиск помогает найти близкую реализацию, даже если разработчик сформулировал задачу иначе. Граф показывает структуру зависимостей и кандидатов влияния. Пересортировка результатов помогает поднять наиболее относящиеся к запросу фрагменты. Ни один из этих способов сам по себе не доказывает, что найденная функция обязательно вызывается во всех интересующих сценариях.
Поэтому после обнаружения LEM может перейти к более строгой проверке. Exact — слой точных структурных фактов, привязанных к определённому снимку проекта. В ответе важно не только имя процедуры, но и файл, место в модуле, версия кода в Git, полнота охвата и вид связи. Предполагаемая связь, динамический вызов и неразрешённый кандидат отмечаются отдельно. Если часть проекта не охвачена, пустой результат не доказывает отсутствие зависимости.
Это особенно полезно при работе локального агента с небольшим контекстным окном: он получает ограниченную область и признаки достоверности вместо неразобранной выгрузки. Однако уменьшение токенов или повышение качества ответа — измеряемые эффекты конкретного сценария, а не универсальная гарантия.
От вопроса о функции к кандидату правки
Допустим, меняется процедура общего модуля, которая готовит данные обмена. Сначала агент ищет её определение и места вызова, затем смотрит, какие формы, модули и расширения могут зависеть от результата. Если у проекта есть библиотечные источники, он уточняет версию API и требования к формату. Встроенный гид LEM помогает выбрать доступный проект, проверить готовность снимка и перейти от поиска к нужному виду анализа. Только после этого агент предлагает изменение.
Для проверки не нужно сразу менять основной индекс проекта. Overlay — временный слой правок поверх выбранного исходного снимка: агент передаёт небольшой diff, то есть список изменённых строк, или свои ещё не включённые в Git файлы. LEM сравнивает кандидат с конкретным базовым commit, позволяет исследовать затронутые связи и затем удаляет временный слой. Изменение в overlay не становится новым состоянием main.
Pull request (PR) — предложение включить ветку с правкой в основную ветку Git. Для его проверки LEM сопоставляет исходный и целевой commit; для ещё не оформленной правки использует overlay. Отдельный обзор изменений 1С собирает доступные статические факты по BSL и метаданным, разницу версий и сведения о порядке расширений, если нужные источники предоставлены. Общий обзор PR для других языков не заменяет этот 1С-анализ автоматически. Отчёт показывает, какой снимок проверен, что доказано, где результат неполон и что нужно проверить вручную. Рекомендованные тесты — план, а не сообщение об уже выполненном запуске.
Кандидаты на замену из библиотечного корпуса
Если стандарт команды требует пользоваться БСП, агент может найти в проекте самописную реализацию и запросить у LEM возможные замены в нужной версии БСП или другой подключённой библиотеки. LEM ранжирует кандидатов по имени, сигнатуре, смысловой близости и источнику. Это даёт материал для ревью и задачи на рефакторинг: открыть предлагаемый метод, сопоставить параметры и возвращаемое значение, подготовить адресный diff и проверить его влияние. Совпадение по поиску само по себе не доказывает равенства поведения двух процедур.
Что проверяется до запуска 1С
У LEM есть собственный развивающийся статический анализ BSL: он разбирает ограниченную правку и сопоставляет её с уже подготовленными фактами проекта. Он помогает заметить проблемы ещё до загрузки конфигурации или обработки в базу:
- проверяет, удалось ли структурно разобрать изменённый код; неразобранный фрагмент не выдаётся за успешно проверенный;
- сверяет статически разрешённые вызовы с индексированными сигнатурами: существует ли доступная процедура, отмечена ли она как
Экспорт, соответствует ли число переданных параметров обязательным и допустимым; - выводит сведения о типах литералов и переменных, связывает аргументы локальных вызовов с параметрами и показывает возможные типы возвращаемого значения функции. Например, агент может увидеть, что после правки вместо числа по одному из путей возвращается строка, и проверить использующие результат места; сам факт вывода типов ещё не означает, что LEM автоматически доказал ошибку во всех таких случаях;
- использует доступные факты метаданных и статически видимых текстов запросов, чтобы уточнять кандидатов влияния и причины, по которым вывод пока не сделан.
Результат разделяет подтверждённые факты, кандидатов и неразрешённые случаи. Это важно для 1С-кода с динамическими вызовами, составными типами и поведением, зависящим от данных базы: отсутствие найденной ошибки при неполном охвате не означает, что её нет. Подготовленный индекс хранит структуру проекта, сигнатуры и связи, поэтому при каждой адресной проверке не нужно заново просматривать всю конфигурацию. Именно такая предварительная подготовка делает собственный анализ LEM полезным в коротком цикле правки и ревью без обещаний полного покрытия или фиксированной скорости.
Отдельно можно подключить BSL Language Server как дополнительный анализатор. Он даёт свой набор синтаксических и статических диагностических сообщений для выбранных файлов; например, у него есть проверка присваивания свойству только для чтения. Результат зависит от подключённого анализатора и его настроек. Это расширяет список проверок, но не подменяет собственный анализ LEM и не превращает статический результат в доказательство поведения работающей базы.
Такие проверки помогают отсеять часть ошибок раньше дорогого цикла загрузки и запуска 1С. Если задача зависит от проведения документа, данных информационной базы, динамического вызова или порядка выполнения расширений, окончательный вывод требует соответствующего испытания в работающей 1С.
Как читать результат ревью
Представим ревью правки в общем модуле проведения документа. Разработчику важно не просто увидеть «вызов изменился», а понять, какой релиз конфигурации и какое расширение затронуты, откуда вызывается процедура и что происходит с её параметрами и результатом. Хороший отчёт помогает последовательно прочитать:
- Что именно сравнили? Проект, исходный и целевой commit Git либо временный overlay, версии конфигурации, расширений и нужных библиотек.
- Что подтверждено? Изменённый BSL-фрагмент, статически установленные вызовы, доступные сигнатуры и факты метаданных с указанием исходного места.
- Что требует внимания? Возможные связи через динамический вызов, типы параметров и возвращаемых значений, кандидаты на замену из БСП и места, где статический вывод неоднозначен.
- Чего анализ не увидел? Недоступные файлы, усечённый обход связей, неразрешённые вызовы, неполный охват конфигурации или расширений.
- Как завершить проверку? Адресно проверить код и стандарты, выполнить рекомендованные тесты, а для проведения документа, форм и данных базы — испытать изменение в работающей 1С.
Такой порядок полезен не только для большого рефакторинга. Он подходит для исправления одного метода, проверки небольшого PR, обновления библиотеки и разбора интеграции. Состав инструментов определяется задачей: иногда достаточно библиотечного ответа с версией и строкой источника; иногда нужен полный проектный анализ.
Посмотреть открытые примеры поиска и доказательств можно в демонстрации LEM. Анализ собственного проекта и PR проводится в отдельном пилоте с согласованным доступом к исходникам.