Почему не рекомендуется использовать хардкод числовых значений в коде
Что проверяют
Видите ли вы разницу между магическим числом и осмысленной константой и понимаете ли, где значению место: в коде, в конфигурации или в базе. Вопрос простой, но по ответу видно, сопровождал ли человек чужой код.
Как отвечать
Проблема не в числе, а в потерянном смысле. if (status == 3) не сообщает, что речь про отменённый заказ, поиск по коду по цифре ничего не даёт, а одно и то же значение, повторённое в трёх местах, рано или поздно разъезжается.
Дальше разложить по уровням, где значению жить.
- Именованная константа для того, что действительно постоянно:
private static final int MAX_RETRIES = 3;. Для набора взаимоисключающих значений не число, а enum. - Конфигурация для того, что отличается между стендами: таймауты, размеры пулов, адреса. В Spring это
@ConfigurationPropertiesповерхapplication.ymlс возможностью переопределить переменной окружения. - База или фиче-флаг для того, что меняют без релиза: лимиты, тарифы, пороги.
Полезно сразу оговорить, где литерал нормален: 0 и 1 в цикле, деление на 100 в методе с говорящим именем, значения из спецификации, вынос которых только запутает. Тесты тоже исключение: ожидаемый результат лучше писать явным числом, а не повторять в нём формулу из кода.
Где спотыкаются
Выносят в константы всё подряд, вплоть до единицы под именем. Имя, повторяющее значение, смысла не добавляет, а лишний переход по коду мешает читать.
Заводят общий класс со всеми числами проекта. Получается свалка без контекста: связь значения с местом использования теряется, класс тянут в каждый модуль, а править его боятся. Константа должна лежать рядом с тем, кто ею пользуется.
Путают константу и настройку. Таймаут запроса или лимит выгрузки, зашитый как static final, требует пересборки ради одной цифры. Признак простой: если значение может отличаться на стенде и в проде, это конфигурация.