Как быстро разобраться в чужом коде с помощью локальной LLM

В справочнике дополнительных отчётов и обработок любой базы, которая живёт больше трёх лет, лежит два-три десятка файлов. Часть писали вы, часть предыдущий разработчик, часть прислал подрядчик. Завтра одну из них надо будет править, и первый вопрос будет не "как править", а "что она вообще делает".

Обычный ответ на этот вопрос - открыть и читать. Полторы тысячи строк это полдня, если повезёт и код разбит на процедуры с говорящими именами. Если не повезёт, день.

Ниже способ уложиться в пять минут. Не вместо чтения, а до него: чтобы понять, что читать, в каком порядке и на что смотреть внимательно.

Что здесь работает, а что нет

Сразу оговорю, чтобы не тратить ваше время, если ждёте другого.

Не работает: дать локальной модели чужой код и попросить найти проблемы. Мы это замерили: на 18 фрагментах с заранее известными дефектами локальные модели нашли ноль и семнадцать раз ответили, что код корректен. Модель, которой дали искать, успокаивает на любом коде.

Работает: разделить работу. Обычный статический анализатор ищет и даёт номера строк, локальная модель объясняет найденное человеческими словами и рассказывает, что процедура делает. Модель при этом не может выдумать дефект: находка пришла не от неё.

Всё считается на вашей машине. Чужой код в облако отправлять нельзя, и это не паранойя, а обычное условие работы.

Шаг 1. Достать текст модулей

Нужны два текста: модуль объекта и модуль формы. Открываете обработку в конфигураторе и копируете.

Что даёт шаг: дальше всё работает с текстом, а не с файлом. Значит способ одинаково годится для управляемых и обычных форм, для файла с диска и для обработки из справочника - откуда вы взяли текст, роли не играет.

Один момент, который экономит время позже: не склеивайте два модуля в один кусок. Если их объединить, нумерация второго уедет на длину первого, и все номера строк в отчёте перестанут совпадать с тем, что вы видите в конфигураторе. Разбирать надо по модулю.

Шаг 2. Получить описание логики

Первое, что нужно, - не список ошибок, а ответ на вопрос "что этот код делает". Его даёт модель по тексту модулей.

Выглядит это примерно так, живой пример с обработки выгрузки остатков:

Назначение: процедура выгружает остатки по складам и отправляет уведомление в Telegram. Проверяет дату документа, ищет склады по коду, для каждого получает остатки запросом и накапливает лог.

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

Сопровождение: начинать чтение стоит с процедуры выгрузки, там собран весь порядок работы; отправка вынесена отдельно.

Что даёт шаг: вы получаете карту. Дальше читать код можно не подряд, а с той процедуры, которую модель назвала главной.

Здесь же стоит сказать про доверие. Проверить пересказ можно машиной: выписать из ответа все имена и поискать их в исходнике грепом. Чего в файле нет, то модель придумала. На ста чужих обработках модель назвала 71 имя, из них 67 реально есть в исходнике, четыре искажены склонением, выдуманных с нуля ноль.

Ноль выдумок - это прямое следствие того, что модель не ищет. Ей нечего выдумывать.

Шаг 3. Посмотреть на находки сверху вниз

Анализатор возвращает список: правило, уровень, модуль, номер строки, процедура. Уровней пять - Blocker, Critical, Major, Minor, Info.

Читать надо не подряд, а сверху: сначала Blocker, потом Critical. Остальное подождёт до того, как вы решите, стоит ли вообще трогать эту обработку.

Что даёт шаг: вы за минуту понимаете, во что ввязываетесь. Обработка с двумя блокерами и оценкой качества 9 из 100 - это не "поправить строчку", это переписывать.

Шаг 4. Прочитать объяснение и способ починки

По каждой находке приходят три вещи, и разница между ними важна.

Объяснение пишет модель: что не так в этом конкретном месте и чем кончится на рабочих данных. Помечено бейджем, может ошибаться.

Фрагмент кода вокруг находки с подсвеченной строкой. Это чистые данные, ваш собственный текст.

Способ починки берётся из реестра правил и печатается дословно. Модель его не пишет, и это принципиально.

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

Сам этот совет кодом и остальные восемь я разбирал отдельно - Как прикрутить локальную модель к 1С, чтобы она не врала. Здесь важно только следствие: способ починки в отчёте пишет не модель.

Что даёт шаг: вы получаете и объяснение по-человечески, и точный рецепт, и при этом знаете, какая часть проверяема, а какая нет.

Шаг 5. Взять план и решить, браться ли

Последнее, что нужно перед тем, как открыть конфигуратор, - порядок работ и цена вопроса.

План строится по уровню правила: сначала блокирующее, потом критичное. Строки группируются по правилу, а не сыплются вперемешку: одно правило на четырёх строках это одна правка, а не четыре.

Рядом - оценка: индекс качества от 0 до 100, светофор и технический долг в минутах. Долг считается по весу правил, у нас от 10 до 60 минут на находку.

Что даёт шаг: у вас появляется число для разговора с заказчиком или руководителем. "Тут на девять часов" звучит иначе, чем "тут всё плохо".

Сколько это занимает на самом деле

Живой прогон. Обработка на 1 309 строк модуля объекта плюс 500 строк модуля формы, писали несколько лет, я её до того не открывал.

Полторы минуты против полудня чтения. Причём читать всё равно придётся - но уже зная, куда смотреть.

Проверка на объёме: сто чужих обработок

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

Один случай на этом прогоне выглядел как дефект и оказался правотой анализатора: модуль формы на 1 601 строку дал ноль находок. Проверил - 1 580 строк из них комментарии, живого кода шестнадцать строк. Закомментированное он не считает, и это правильно.

Что чаще всего лежит в чужом коде

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

Четыре первых места из шести - это одно и то же: что-то тяжёлое внутри цикла. Запись, вывод, склейка строки, обращение к базе. Больше половины всех находок корпуса.

Это меняет то, как я теперь читаю чужой код. Раньше смотрел сверху вниз, сейчас первым делом ищу циклы и смотрю, что внутри. На незнакомой обработке это даёт больше за минуту, чем последовательное чтение за час.

По уровням расклад такой: 39 блокирующих, 300 критичных, 456 значительных. То есть блокирующее - редкость, примерно одно на три обработки, а вот критичное есть почти везде.

И отдельно про пустой блок Исключение, 59 случаев. Он не тяжёлый по производительности и потому не бросается в глаза, но именно из-за него потом невозможно понять, почему обмен молча не отработал. Ошибка была, её проглотили, в журнале пусто.

Что я нашёл в своём собственном инструменте

Отдельно прогнал двадцать две наши обработки. Ожидал, что свой код чистый.

Не чистый. В одной 32 находки и четыре блокера, в другой 37, в третьей 29. Полностью чистых оказалось четыре из двадцати двух.

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

Токен = "<span style='color:#008000'>//";

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

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

Мораль шире одного правила: ложное срабатывание на высшем уровне дороже пропуска. Пропущенную находку вы не заметите, а Blocker на ровном месте заставит вас усомниться во всём отчёте.

А если обработок не одна, а тридцать

Разбирать по одной имеет смысл, когда вы уже знаете, какую. Обычно не знаете: в справочнике лежит три десятка файлов, и вопрос звучит иначе - с какой вообще начинать.

Тут порядок другой и модель не нужна вовсе. Анализатор гоняется по всем сразу, без объяснений, и выдаёт сводный рейтинг: индекс качества по каждой обработке, число находок, техдолг. Это быстро - весь корпус из ста обработок у меня разобрался за 141 секунду, то есть примерно полторы секунды на обработку.

Дальше берёте худшие по индексу и уже к ним применяете пять шагов выше. Модель включается только на тех, которые вы отобрали, и тратится она на десяток обработок, а не на тридцать.

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

И обратный случай, который встречается чаще, чем кажется: крупная обработка даёт ноль находок. Иногда это правда чистый код, а иногда - тот самый модуль, где живого кода шестнадцать строк из полутора тысяч, а остальное закомментировано. Рейтинг покажет это до того, как вы сядете читать, и сэкономит полдня.

Чего этот способ не даёт

Честный список, чтобы не было разочарования.

Не находит логических ошибок. Анализатор видит типовые дефекты по структуре кода: запрос в цикле, транзакцию без отката, секрет в литерале. Он не знает, что вы хотели сделать, и не поймает "тут должно быть больше, а не меньше".

Не заменяет чтение. Он сокращает его и задаёт порядок. Править код всё равно вам.

Объяснения модели могут ошибаться. 94 процента имён верны, но не 100. Читайте их как объяснения, а не как приговор.

Нужна установка. Локальная модель это 1,9 ГБ на диске и пять минут на первую настройку. Дальше бесплатно и без интернета, но первый раз потратить придётся.

Что нужно, чтобы повторить

Ollama, любая машина с Windows и 1С 8.3. Видеокарта не обязательна: на карте с 4 ГБ ответ занимает 8-15 секунд, без карты минуту. Модель качается один раз, подписок и токенов нет.

Если в отделе есть одна машина с приличной картой, ставить каждому не нужно: адрес сервиса задаётся настройкой.

Собранная связка лежит здесь: ИИ-анализ кода 1С: логика, находки и рекомендации на локальной модели. Отдельно анализатор без модели - Анализ кода внешних обработок 1С.

А как разбор устроен изнутри и что именно подавать модели на вход, чтобы она не врала, я разбирал отдельно: Как прикрутить локальную модель к 1С, чтобы она не врала.

Другие наши инструменты для работы с нейросетями:

• Выгрузка структуры метаданных для нейросети - чужой код понятнее, когда модель видит и структуру базы, под которую он написан.
• Матрица прав доступа для нейросети - вторая половина вопроса к чужой обработке: под какими правами она вообще работает.
• Журнал регистрации для нейросети - если после разбора кода надо понять, что эта обработка делала в базе на самом деле.

И вопрос к тем, кто разбирал чужое легаси своими способами: чем меряете, стоит ли вообще браться за обработку, или решаете на глаз? Мне интереснее всего именно эта часть - до правок, а не после.