Какие данные нельзя жёстко зашивать в код?

Любые чувствительные данные вроде паролей, API-ключей, приватных сертификатов или конфигурационных параметров инфраструктуры. Даже казалось бы безобидные строки подключения к БД или эндпоинты внешних сервисов не должны появляться в исходниках - это прямой путь к уязвимостям при утечке кода или смене окружения.

Сейчас для этого лучше всего подходят системы управления секретами вроде HashiCorp Vault или облачные Key Management Services. Конфиги же стоит выносить в environment variables или специализированные конфигурационные файлы, которые не коммитятся в репозиторий, а подгружаются на этапе деплоя.

Жёсткое кодирование критически опасно для конфиденциальных данных: паролей, API-ключей, токенов доступа и приватных сертификатов. Уязвимыми также становятся параметры инфраструктуры - IP-адреса серверов, порты подключения, пути к файловым системам.

Любые данные, которые могут меняться в зависимости от среды развёртывания (dev/stage/prod) или требуют регулярного обновления, должны храниться отдельно от кода. Это касается лимитов системы, бизнес-правил и даже текстов локализации. Жёсткая привязка таких значений усложняет поддержку и создаёт риски утечек.

В моей практике было так: однажды целый отдел два дня искал ошибку в программе, а виной всему был жёстко прописанный путь к папке на диске C. Как только программу перенесли на другой компьютер, всё рухнуло. Так что, дорогой мой, нельзя в код зашивать ничего, что может измениться: адреса серверов, названия баз данных, имена файлов с логами, да даже номер порта, если вы используете нестандартный. А уж тем более, пароли и ключи - это вообще не обсуждается. Всё это хозяйство храни в конфигах или в специальных менеджерах, а в коде оставляй только ссылки на них.

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

Сложность в том, что даже мелочи могут аукнуться. Я бы на твоём месте избегал зашивать любые числовые магические константы, которые неочевидны из контекста - например, «86400» вместо «SECONDS_IN_DAY», или «0.07» без комментария, что это за коэффициент.

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