1C Extension Auditor — инструмент для анализа совместимости расширений 1С после обновления типовой конфигурации.

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

Также рассказываю, чем Auditor отличается от 1C Extension Checker 2.0 и как эти инструменты могут использоваться вместе.

Проект продолжает развиваться. В следующей статье планирую проверить, насколько бесплатные ИИ-модели могут помочь в анализе изменений кода 1С и объяснении потенциальных рисков.

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

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

Для предварительной проверки таких ситуаций мы разработали 1C Extension Checker 2.0 — самостоятельную внешнюю обработку, которая помогает проверить подключённые расширения и зафиксировать обнаруженные проблемы в едином протоколе.

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

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

Переобучение ловится честной валидацией. Утечки — дисциплиной признаков. Сидовый шум — ансамблями. А смена режима не ловится ничем заранее: вы узнаёте о ней тогда, когда система уже теряет деньги в реальном времени.

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

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

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.