Как мы строим

Проверка показывала 43 замечания. В коде было 66

Базовая линия считала только выданные замечания и не видела подавленные. Двадцать три случая были закрыты комментарием и не попадали в счёт — рост долга шёл мимо цифры.

Александр Цапков10 сентября 20262 мин

У нас была базовая линия по замечаниям линтера: число в файле, и гейт следит, чтобы оно не росло. Гейт показывал 43. В коде было 66.

Куда девались двадцать три

Линтер считает то, что выдал. Замечание, закрытое комментарием-подавлением, он не выдаёт — значит, в счёт оно не попадает.

Механика простая и от этого коварная: разработчик ставит подавление, число в базовой линии не меняется, гейт зелёный. Долг вырос, цифра — нет.

Пока подавлений мало, разница незаметна. К моменту, когда мы посчитали руками, она составляла треть.

Почему это хуже, чем просто неточность

Базовая линия существует ради одной вещи: видеть направление. Растёт число или падает. Если один из способов «закрыть» замечание не попадает в счёт, направление перестаёт быть видимым — а решение о том, пора ли чинить, вы всё равно принимаете по цифре.

Получается проверка, которая отвечает на вопрос, которого ей не задавали: «сколько замечаний выдано» вместо «сколько замечаний есть».

Что сделали

Завели вторую базовую линию — на подавления, с отдельным гейтом. Правило такое:

Подавление — это не решение замечания, а договорённость о нём молчать.

Поэтому число подавлений считается отдельно, растёт только осознанно, и рядом с каждым новым обязана стоять причина в коде. Гейт при росте говорит прямо: почините случай либо объясните причину и поднимите число той же правкой — тогда рост виден в истории, а не растворяется.

Как проверить у себя

# сколько подавлений в коде на самом деле
grep -rn "eslint-disable" src/ | wc -l

# и по правилам, чтобы понять, что именно замалчивается
grep -rho "eslint-disable[a-z-]*-line \([a-z@/-]*\)" src/ | sort | uniq -c | sort -rn

Сравните первое число с тем, что показывает ваш гейт. Если они разные — у вас та же история.

Что из этого следует

Это частный случай правила, которое мы записали после трёх похожих находок за один день: зелёный, который ничего не проверил, опаснее красного.

Красный виден и его чинят. Зелёный, считающий не то, воспринимается как доказательство — и тем прочнее, чем дольше стоит. Гейт секретов у нас зеленел на обрезанной истории, гейт зависимостей принимал пустой ответ реестра за «уязвимостей нет», а этот считал выданное вместо существующего.

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


Мы держим этим набором шестьдесят с лишним проверок, и каждая из них объясняет в своей шапке, почему существует. Как устроена документация проекта, которая переживает уход человека — Документы.

Документация и база знаний проектаВики проекта со ссылками между документами, графом связей и версией на каждую правку.

Читайте также

Автор

Александр ЦапковОснователь Скоупворк

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