В справочнике дополнительных отчётов и обработок любой базы, которая живёт больше трёх лет, лежит два-три десятка файлов. Часть писали вы, часть предыдущий разработчик, часть прислал подрядчик. Завтра одну из них надо будет править, и первый вопрос будет не "как править", а "что она вообще делает".
Обычный ответ на этот вопрос - открыть и читать. Полторы тысячи строк это полдня, если повезёт и код разбит на процедуры с говорящими именами. Если не повезёт, день.
Ниже способ уложиться в пять минут. Не вместо чтения, а до него: чтобы понять, что читать, в каком порядке и на что смотреть внимательно.
Что здесь работает, а что нет
Сразу оговорю, чтобы не тратить ваше время, если ждёте другого.
Не работает: дать локальной модели чужой код и попросить найти проблемы. Мы это замерили: на 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 минута 16 секунд |
| Найдено | 6 находок, из них 1 блокирующая |
| Индекс качества | 39 из 100, светофор красный |
| Технический долг | 180 минут |
Полторы минуты против полудня чтения. Причём читать всё равно придётся - но уже зная, куда смотреть.
Проверка на объёме: сто чужих обработок
Одна обработка это не замер. Поэтому я прогнал связку по ста внешним обработкам, которые писали разные люди годами: сто тысяч строк, моего кода там ноль.
| Модулей разобрано | 159 |
| Находок | 1 135 |
| Падений | 0 |
| Номеров строк за пределами файла | 0 |
| Плотность | 11,3 находки на 1 000 строк |
| Время на весь корпус | 141 секунда |
Один случай на этом прогоне выглядел как дефект и оказался правотой анализатора: модуль формы на 1 601 строку дал ноль находок. Проверил - 1 580 строк из них комментарии, живого кода шестнадцать строк. Закомментированное он не считает, и это правильно.
Что чаще всего лежит в чужом коде
Раз уж набралось 1 135 находок на ста обработках, вот их распределение. Мне оно показалось полезнее самих чисел: видно, чего ждать, открывая незнакомый файл.
| Запись объекта БД внутри цикла | 239 |
| Сообщить() внутри цикла | 212 |
| Накопление строки конкатенацией в цикле | 151 |
| Точечное чтение из СУБД в цикле (НайтиПоКоду, СрезПоследних) | 144 |
| Цикломатическая сложность выше 20 | 69 |
| Пустой блок Исключение | 59 |
Четыре первых места из шести - это одно и то же: что-то тяжёлое внутри цикла. Запись, вывод, склейка строки, обращение к базе. Больше половины всех находок корпуса.
Это меняет то, как я теперь читаю чужой код. Раньше смотрел сверху вниз, сейчас первым делом ищу циклы и смотрю, что внутри. На незнакомой обработке это даёт больше за минуту, чем последовательное чтение за час.
По уровням расклад такой: 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С, чтобы она не врала.
И вопрос к тем, кто разбирал чужое легаси своими способами: чем меряете, стоит ли вообще браться за обработку, или решаете на глаз? Мне интереснее всего именно эта часть - до правок, а не после.
Вступайте в нашу телеграмм-группу Инфостарт
