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

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

В двух словах

Надёжно — категория A (алгоритмика), оси Синтаксис и Семантика. Оценку ставят автоматические проверки, результат воспроизводим.

Надёжно — категория B (платформа), оси Семантика и Платформа. Стали надёжными, когда код начали по-настоящему запускать в 1С.

Осторожно — Оптимальность. Где заведён нагрузочный замер — машина судит по делу, по классу роста. Где замера нет — только по виду кода, грубо. Удачен ли сам подход — не судит вовсе.

Пока не доказано — согласие машины с экспертом. Наш главный аргумент, но эксперт был только один.

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

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

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

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

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

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

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

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

Что мы делаем, чтобы границы расширить

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

Больше задач — чтобы рейтинг перестал быть «в пределах шума».
Разметка двумя-тремя экспертами — чтобы впервые честно измерить согласие машины и эксперта, а не верить ему авансом.
Раздельная настройка и проверка — пороги метрики настраивать на одних задачах, а согласие проверять на других.
Честная оптимальность — O меряется исполнением уже и в алгоритмике (A), и в платформенных задачах (B, где заведён замер). Осталось откалибровать её против эксперта на Уровне 2 и честно оговаривать предел там, где машина слепа (архитектура решения; порок, спрятанный целиком в памяти).

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

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