Честные границы

Любой бенчмарк может нарисовать красивый рейтинг. Гораздо честнее — прямо сказать, что работает и чем это подтверждено, где цифрам уже можно верить, а где пока рано. Эта страница про это. Правила и пороги живут в файлах метрики (metrics/), здесь только карта состояния.

В двух словах

• Надёжно — категория A (алгоритмика), оси Синтаксис и Семантика. Оценку ставят автоматические проверки, результат воспроизводим.
• Надёжно — категория B (платформа), оси Семантика и Платформа. Стали надёжными, когда код начали по-настоящему запускать в 1С.
• Осторожно — Оптимальность. Где заведён нагрузочный замер — машина судит по делу, по классу роста. Где замера нет — только по виду кода, грубо. Удачен ли сам подход — не судит вовсе.
• Пока не доказано — согласие машины с экспертом. Наш главный аргумент, но эксперт был только один.

Что уже работает

Свежие цифры прогона — на странице Лидерборд, устройство внутри — в Архитектуре.

Чему уже можно верить

Алгоритмика (категория A), оси Синтаксис и Семантика. Оценку ставят автоматические проверки — компилятор и тесты. У них нет настроения и мнения: тот же код прогонишь дважды — получишь тот же балл. Это и есть надёжность.

Платформа (категория B), оси Семантика и Платформа. Код по-настоящему запускается в 1С против синтетической базы, и запуск видит то, чего не видно глазами: например, что модель обратилась к полю, которого в базе нет. Статической сверки имён со срезом схемы конфигурации в оценке нет вовсе, и это осознанное решение, а не упущение: её баллы расходились с оценкой эксперта в обратную сторону, корреляция Спирмена ρ = −0.27. Чем выше машина ставила балл, тем ниже склонен был поставить человек, то есть инструмент мерил скорее наоборот, чем правильно. Поэтому сверку убрали из оценки целиком, а не «докрутили». По той же причине на исполнение переведена и ось Оптимальность.

Пропуск замера не выдаётся за плохую оценку. Если решение не добралось до базы (модуль не собрался, нужной функции нет), по Платформе стоит «не измерено», а не ноль. Ноль читался бы как «модель обратилась к метаданным и всё перепутала», хотя обращений никто не проверял: прогон до них не дошёл. Рядом с итоговым баллом идёт охват: сколько осей из применимых действительно измерено. Это важно, потому что итог усредняет только измеренное, и без охвата запись с двумя проверками выглядела бы наравне с записью, за которой стоят четыре.

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

Где пока рано доверять

1. Согласие машины с экспертом ещё не доказано. Главная идея PRISM: машинной оценке можно верить, потому что на проверке она совпадает с живым экспертом. Звучит хорошо — но пока эксперт был только один. А из одного человека «согласие» не посчитать: нужно хотя бы двое-трое, и проверять надо на задачах, которые не использовались для настройки самой метрики. Пока этого нет, называть оценку «подтверждённой экспертами» — аванс, а не факт.

Само это согласие придётся считать аккуратно, и вот почему. Шкала у машины и у эксперта одна — 0 · 2 · 4 · 6 · 8 · 10, но машина достаёт не все её ступени. По Оптимальности ей доступны только {2, 4, 6, 8, 10}: нуля не бывает, потому что она знает лишь ограниченный список проблем и не может утверждать, что всё совсем плохо. По Платформе достижимы {0, 4, 6, 10} — без 2 и 8, потому что машина считает долю тестов, а эксперт смотрит на отдельные обращения к объектам. По Синтаксису недостижима восьмёрка: она отведена модулю, который собирается, но вызывает замечания анализатора, а таких в корпусе нет вовсе — всё, что собирается, собирается чисто. Эксперт же свободно ставит любую ступень. Значит, нижние ступени напрямую несопоставимы, и согласие по этим двум осям надо мерить взвешенной каппой — той, что учитывает, насколько далеко разошлись оценки, а не только факт расхождения. К Оптимальности добавляется ещё одна поправка: эксперт судит её целиком — асимптотика, структура, стиль, — а машина видит только класс роста.

2. Про ось Платформа лог рассказывает не всё. Вердикт «код верно обратился к метаданным» мы собираем из того, что записали 1С и технологический журнал. Журнал честно говорит, трогал ли код данные вообще, и этого хватает, чтобы не ставить высокий балл там, где до базы дело не дошло. Но какие именно объекты трогал код, из него не видно. Поэтому в корпусе остаются девять решений, где все тесты провалились, а Платформа стоит десяткой: обращение к базе было, упали они позже и на обычном коде, так что балл обоснован, а перепроверить его нечем. Отдельный класс ошибок по логу не опознаётся в принципе (строка вместо ссылки в параметре владельца, колонки табличной части не тем аргументом, чтение периодического регистра сведений набором вместо среза): такую ошибку видно только в исходнике решения. prism audit показывает эти случаи отдельным пунктом, а не прячет.

3. Банк задач ещё маленький. Несколько десятков задач — мало, чтобы уверенно заявлять «эта модель лучше той»: разница между моделями может оказаться в пределах случайности. Рейтинг станет весомым, когда задач станет заметно больше и они станут разнообразнее. Поэтому пополнение банка — наш приоритет №1.

4. Оптимальность (O) меряется исполнением. В алгоритмике (A): подаём решению большой объём входных данных и смотрим, как растёт число операций, — так машина различает быстрый алгоритм и медленный (вплоть до низких баллов). В платформенных задачах (B, где заведён замер): наращиваем базу и смотрим, как растёт число обращений решения к СУБД — набором (одним запросом) обращения не растут, «запрос в цикле» растёт. Так сложность ловится по эффекту, а не по виду кода, и вдобавок машина не льстит неисполнимому коду (не запустился → оценка не ставится). Задачи без нагрузочного профиля оцениваются статической проверкой «по виду кода». «Удачно ли выбран подход» и неалгоритмическую оптимальность (структура, стиль) машина не судит — это Уровень 2.

Что дальше

По приоритету:

1. Больше задач. Банк пока небольшой, а от числа и разнообразия заданий напрямую зависит, можно ли уверенно говорить «эта модель лучше той». Пока рейтинг во многом «в пределах шума», поэтому рост банка — приоритет №1 (как добавить — Как участвовать).
2. Разметка двумя-тремя экспертами. Первое настоящее измерение согласия машины и эксперта, а не вера ему авансом. Это главный научный результат проекта, и он ещё впереди.
3. Раздельная настройка и проверка. Пороги метрики настраивать на одних задачах, а согласие проверять на других.
4. Честная оптимальность. O меряется исполнением и в алгоритмике (A), и в платформенных задачах (B, где заведён замер). Осталось откалибровать её против эксперта на Уровне 2 и честно оговаривать предел там, где машина слепа: архитектура решения, порок, спрятанный целиком в памяти.
5. Открытый прогон на актуальных моделях — больше моделей и генераций, свежие цифры на лидерборде.
6. Проверки категории B на YAXUNIT — стандартный для 1С формат модульных тестов; сейчас формат свой, при переходе смысл проверок сохранится.
7. Скорость категории B — кэш собранной базы под каждую задачу. Два шага уже сделаны: параллелизм (PRISM_CONCURRENCY, ~10–20 секунд на кандидата) и кэш сырых замеров по содержимому входа. Второй важнее для исследования: смена правил оценки не требует гонять 1С заново, пересчёт корпуса стоит минуты вместо часов. Осталась сама сборка базы.

Почему мы это вообще пишем

Потому что честный измеритель важнее красивого рейтинга. Если мы говорим «модель X лучше» — за этим должно стоять то, что мы готовы открыто показать, включая собственные слабые места.