Три формы одной болезни
- Одна норма в нескольких редакциях. Каждая появилась законно: одна из внешнего стандарта, другая из его же более мягкого пункта, третья — фактическое условие в коде, четвёртая — число в комментарии рядом с этим условием. Ни одна не помечена главной.
- Прямая инверсия. В одном документе требование звучит как «должно совпадать», в другом — «не должно». Инструменты при этом исполняют ту версию, которую верхний документ уже отменил.
- Противоречие внутри одного файла. Тот самый случай «ровно 4» и «20» на соседних страницах одного документа. Он показателен: это не спор двух авторов, а один автор в два захода.
Практическое следствие — вердикт зависит от того, кто спросил. Одна и та же страница получает разные оценки от трёх наших же проверок, потому что каждая держит свою редакцию нормы. Спор «кто прав» бессмыслен: правы все, норма не одна.
Зеркальная дыра: гард без требования
Обычно ищут требования, которые никто не проверяет. Мы посчитали и обратное — и вторая половина оказалась не менее интересной.
| Дыра | Что это значит |
|---|---|
| Требование без проверки | правило записано, его исполнение никем не контролируется. Держится на памяти и добросовестности — то есть до первой запарки |
| Проверка без требования | правило живёт только в коде: его нельзя оспорить, унаследовать или объяснить заказчику. Оно есть, но его как бы нет |
У нас нашлось и то и другое. Самое проверяемое правило одного из направлений — единственное полностью автоматизированное — не записано ни в одном из четырёх профильных документов. Порогов, живущих только в коде, набралось пять.
Приём, который это вскрывает, стоит один вечер. Возьмите свои требования списком и на каждое ответьте одним словом: чем проверяется. Не «должен проверять такой-то» — а запускалось ли это хоть раз и когда. Колонка заполняется прогоном, не памятью. У нас без исполнителя оказалась примерно треть требований.
Отдельный сорт: порог, который печатают, но не применяют
Худшее сочетание из встреченных: инструмент печатает нормы в отчёте — выглядит как работающий контроль, — но фактический порог отсечения выставлен в ноль. То есть не отсекается ничего, а в отчёте нормы аккуратно перечислены.
Рядом — два инструмента одной системы, дающие противоположный вердикт по одному и тому же объекту. Пока их отчёты не кладут рядом, оба выглядят исправными.
Как отличить работающий порог от напечатанного. Подсуньте объект, который заведомо обязан не пройти. Прошёл — порог декоративный, сколько бы норм ни печаталось в шапке отчёта. Это тот же позитивный контроль, только применённый к порогу, а не к детектору.
Что мы поменяли у себя
- У каждой нормы одно место жительства. Число живёт в одном файле, остальные ссылаются. Разночтение становится видимым: два разных значения в двух местах — это расхождение, которое надо снять, а не «уточнение».
- Требования сверяются с кодом сплошняком, а не выборочно. Выборка всегда попадает на то, что помнишь, — то есть на работающее.
- Норма без проверки помечается прямо в документе. Не «надо бы автоматизировать», а честная отметка: контроля нет, держится на человеке.
- Порог проверяется объектом, который обязан упасть.
Зачем это читателю, у которого нет двадцати документов. Болезнь заводится с двух: инструкция и код. Как только число написано в обоих местах, начинается расхождение — вопрос только в том, через сколько месяцев вы его заметите и найдёте ли раньше клиента.