Как найти «мёртвые» правила в проекте, которым вы подчиняетесь зря

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

Потом я прогнал grep. Первая константа после строки объявления не встречается больше нигде. Вторая — ровно один раз, внутри сообщения в лог, и ни в одном сравнении. Ни та, ни другая не участвует в решениях, которые принимает программа.

Так работает целая порода правил: выглядят живыми, ощущаются живыми, а на деле не подключены. Неприятное тут даже не баг. Неприятно, насколько комфортно мне было им подчиняться.

Почему такие правила живут годами

Константы стояли блоком наверху файла — ровно там, где обычно и живут ручки настройки. Правдоподобные имена. Разумные комментарии. И главное, они выжили: выживание само по себе читается как знак качества. Правило, которое лежит давно, кажется проверенным. Чаще это значит другое — его просто никто не оспаривал.

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

Найти его можно только одним способом: пойти и посмотреть. В спокойный день, когда ничего не горит и повода нет.

Мёртвое правило и устаревшее: в чём разница

Проверка на полчаса

1. Возьмите имя константы и прогоните поиск по всему репозиторию, а не по одному файлу. Ищите места, где она участвует в сравнении или ветвлении. Объявление в блоке констант не значит ничего.
2. Посмотрите, как именно она используется. Константа, подставленная в сообщение лога, — декорация: программа от неё ничего не меняет. Порог — это то, что стоит в условии.
3. Измерьте реальную границу. Подайте на вход пример, который заведомо нарушает правило, и посмотрите, в какой момент сработает штраф. У меня оба реальных порога не совпали с написанным в комментариях, причём в разные стороны: один штраф включался заметно раньше заявленного, второй разрешал больше, чем я себе позволял.
4. Заведите тест на фактический порог. Это единственное, что мешает следующему читателю поверить комментарию.
5. Пересмотрите свои ручные ритуалы: что вы делаете сами, потому что «так принято», и какая автоматика это подтверждает. Если подтверждать нечем — вы держитесь на памяти.

Где это прячется кроме кода

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

Типичные ошибки при такой проверке

• Верить комментарию рядом с константой. Комментарий рассказывает про замысел, а не про поведение.
• Считать «лежит давно» доказательством того, что правило проверяли.
• Чистить только то, что упало. Этот класс ошибок падать не умеет.
• Оставлять пункт в чек-листе, потому что удалять страшнее, чем держать.

Когда трогать не надо

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

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