Хардкодить что это

Понимаем сленг программистов: мини-словарь для начинающих разработчиков

Начинающие разработчики не сразу понимают старших товарищей. Фразы вроде «я апишку свитчнул» или «заимпорти другую либу» звучат для новичков как лекция по математическому анализу для первобытного человека. Поэтому мы решили сделать небольшой словарь профессионального сленга программистов.

Слова и фразы в словаре отсортированы по алфавиту. Кстати, словарь можно дополнять. Пишите в комментариях термины, с которыми вы сталкивались на работе.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

А

Адаптив — адаптивный дизайн, адаптация интерфейса к использованию на разных экранах.

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

Айдишник — id, идентификатор.

Альфа — этап разработки программного обеспечения, на котором разработчики добавляют в программу новые функции, а тестировщики испытывают программу. Это внутренний или непубличный этап.

Апишка — API, программный интерфейс приложения или интерфейс прикладного программирования.

Апрув, апрувнуть — от англ. Approve. Одобрение, одобрить, утвердить.

Аутсорс — аутсорсинг, передача компанией части операционной деятельности другой компании.

Б

Баг — от англ. Bug — жучок, клоп. Ошибка в программе.

Бахнуть — что-то быстро сделать, изменить или дополнить функциональность приложения.

Бета — бета-версия, приложение на стадии публичного тестирования.

Бот — сокращение от «робот». Ботом называют программу, которая автоматизирует интерфейс. Пример — автоответчик в чате.

Бэкап, бэкапить — резервная копия или процесс создания резервной копии приложения.

Бэкенд — от англ. Back-end. Программно-аппаратная или серверная часть приложения.

Бэклог — от англ. Backlog. Перечень рабочих задач команды разработчиков, упорядоченный по приотритету.

В

Ворнинг — от англ. Warning — предупреждение. Предупреждающее сообщение в интерфейсе.

Войтивайти — шуточное выражение, обозначает процесс переквалификации далекого от IT-сферы специалиста в разработчика.

Выкатить — сделать доступным для пользователей. Например, «выкатили новую версию сайта» значит сделали новую версию сайта доступной для пользователей.

Выпадашка — выпадающее меню, то же, что и «дропдаун».

Г

Галера — компания, в которой платят низкие зарплаты и не ценят разработчиков.

Гит — система контроля версий Git или сервис GitHub.

Г****окод — плохой, некачественный код. Объяснение термина есть в статье нашего студента.

Градиент — плавный переход из одного цвета в другой.

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

Д

Движок — в веб-разработке так называют системы управления контентом.

Дебажить — устранять ошибки, баги.

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

Джун, джуниор — от англ. Junior. Младший разработчик. Специалист без опыта или с минимальным опытом работы.

Дезигнер — презрительно-снисходительное название дизайнера.

Докеризировать — завернуть приложение в докер (платформу для разработки, доставки и запуска контейнерных приложений).

Драй — от англ. DRY, don’t repeat yourself. Принцип программирования, предлагающий избегать повторений кода.

Дропдаун — выпадающее меню, то же, что и «выпадашка».

Дропнуть — от англ. Drop. Удалить, отключить, сбросить или обнулить что-либо.

Ж

Жаба — язык программирования Java.

Жабаскрипт — язык программирования JavaScript.

З

Залить — загрузить. Например, «залить файлы на сервер».

Запилить — сделать что-то, добавить какую-то функциональность.

Змея — язык программирования Python.

И

Исходник — файлы, в которых находится исходный код приложения, или сам исходный код.

Итерация — повторение. «Мы сделали несколько итераций» — мы повторили шаг несколько раз.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

К

Колл — от англ. Call. Созвон, онлайн-конференция, онлайн-совещание.

Коммит, коммитить — от англ. To commit — совершать. В контексте работы над приложением — сохранять код в репозитории.

Копипаста — от англ. Copy-Paste. Скопированный откуда-то код.

Костыль — код, который нужен, чтобы исправить несовершенство ранее написанного кода.

Л

Легаси — от англ. Legacy. Морально устаревший код, который не обновляется, но используется. Или код, который разработчик получил по наследству от предыдущих разработчиков.

Либа — от англ. Library — библиотека. Речь идет о библиотеках кода, например, React.

Линтер — общее нарицательное название программ, которые анализируют код и предупреждают разработчика об ошибках.

Лист — от англ. List — список.

Локалка — локальный. Например, локальный сервер или сеть.

М

Мидл — от англ. Middle — средний. Уровень разработчика, следующий за джуниором. Опыт и уровень знаний миддла позволяет ему самостоятельно решать серьезные задачи.

Мёржить — от англ. Merge, сливать. Речь идет об объединении или слиянии веток кода.

Меншить — от англ. Mention — упоминание. Упоминанать в чатах или соцсетях. «Менши меня, когда будет готово» значит «упомяни меня, когда будет готово».

Н

Навбар — навигационный блок на сайте или в интерфейсе программы.

Накатить — внести изменения, задеплоить новую версию приложения. Противоположное термину «откатить».

О

Опенсорс, опен-сорс — от англ. Open Source. Программное обеспечение с открытым исходным кодом.

Откатить — удалить изменения, вернуть предыдущую версию приложения. Противоположное термину «накатить».

Ось — операционная система.

П

Падаван — ироничное название стажера или джуниора.

Пилот — пробная (пилотная) версия продукта.

Питон — язык программирования Python.

Подвал — то же, что и «футер». Элемент структуры страницы, который находится в нижней части и содержит служебную информацию — контакты, ссылки на соцсети, публичная оферта и т. д.

Поплыла вёрстка — некорректное отображение страницы в браузере.

Продакшн или продакшен (продакшн-код) — обозначение кода для рабочей версии приложения.

Пушить — использовать команду push, публиковать что-то.

Пэхапэ — язык программирования PHP, то же, что и «пыха».

Пыха — язык программирования PHP, то же, что и «пэхапэ».

Р

Рекурсия — описание процесса с помощью самого процесса. Например, выражение «рекурсивный вызов функции» описывает ситуацию, в которой функция вызывает сама себя.

Релиз — программное обеспечение на стадии публичного использования. Стабильная версия программы, которая прошла тестирование.

Релокация — перевод сотрудника или бизнеса в другое место внутри страны или за границу.

Репа — репозиторий, хранилище данных. Например, код программы можно хранить в репозитории на GitHub.

Ридми — файл Readme, в котором содержится информация о программе.

Ругаться, например, линтер ругается — сообщения об ошибках в коде, работе сервиса и так далее.

С

Сабж — от английского Subject — тема, предмет. «По сабжу» — по теме обсуждения.

Свитчнуть, свичнуть — переключить. От английского switch.

Сетка — модульная сетка, используется для дизайна и верстки страниц.

Сеньор, синьор — от англ. Senior — старший разработчик.

Сорец (Сорцы) — от англ. Source. Исходный код.

Стек — изначально абстрактный тип данных. В разговорной речи используется для обозначения списка технологий, которые использует разработчик или компания. Пример: «Наш стек — HTML/CSS, JavaScript, React».

Софт — от англ. Software — программное обеспечение.

Софт-скиллы — от англ. Soft skills — знания и качества специалиста, прямо не связанные с профессиональной деятельностью. Примеры: коммуникабельность, проактивность.

Спринт — короткий промежуток времени (до 4 недель), в течение которого scrum-команда выполняет определенный объем работы.

Читайте также: Как джуну найти работу и где лучше начинать карьеру в IT: советы от Хекслета

Т

Таска — от англ. Task. Задание, задача.

Темплейт — от английского Template — шаблон.

Тестировщик — специалист по тестированию программного обеспечения.

Тимлид — от английского Team Lead — руководитель команды. Координатор группы программистов.

У

Убить — удалить что-то. Например, «убить профиль» означает удалить профиль.

Ф

Фидбек — от англ. Feedback — обратная связь.

Фиксить, пофиксить — от англ. Fix. Чинить, починить, исправить.

Фича — функция, возможность. От англ. Feature.

Фреймворк — от англ. Framework — каркас. Инструмент разработки, набор типовых шаблонных решений, упрощающих работу программиста. Примеры: Laravel, Bootstrap.

Фронтенд — от англ. Front-end — клиентская часть приложения.

Х

Хатэмээль, хатээмэль — HTML, язык гипертекстовой разметки.

Хардкодить — статически прописывать в коде данные, которые должны вычисляться динамически. Плохая практика, антипаттерн в программировании.

Хацкер, кулхацкер — ироничное название начинающего специалиста, который считает себя опытным программистом. От английского Hacker и Cool Hacker.

Хедер, хэдер — элемент структуры веб-страницы, находится в верхней части и содержит логотип, меню, служебную информацию.

Хотфикс — от англ. Hotfix. Срочное исправление критических ошибок, уязвимостей или недоработок в программе.

Ц

Цэмээс, цээмэс — от англ. CMS — Content Management System, система управления контентом.

Цээсэс — от англ. CSS — Cascading Style Sheets, каскадные таблицы стилей.

Ч

Чекать, чекнуть, прочекать — от англ. Check. Проверять, проверить.

Ю

Юзать — от английского To use — использовать.

Я

Ява — язык программирования Java.

Яваскрипт — язык программирования JavaScript.

ЯП — язык программирования.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг

Есть 3 проблемы кода, с которыми встречаешься в программировании: Хардкод, Говнокод и Шизокод.

Давайте поговорим об этом.

Хардкод

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

Обычно проблемы этого класса быстро обнаруживаются и легко лечатся.

Говнокод

Это более сложная проблема. Часто субъективная. Грубо говоря — это нарушение стиля кода, принятого в голове, команде или сообществе.

Есть разные стили кода в зависимости от платформы и даже иногда внутри платформы:

• Symfony Coding Standards
• WordPress Coding Standards
• PSR — PHP Standards Recommendations

Это из мира php. В других сообществах ситуация похожая. Сюда же можно отнести истории про таб, таб через 2 пробела или таб через 4 пробела и т. д.

Здесь же возникает проблема чистого кода… например длинные функции на 3-4 страницы, что критикуется. Это не всегда конечно плохо, но часто можно такие функции сделать короче, разбить на ряд коротких функций, каждая из которых решает свою задачу.

Обычно эти проблемы легко лечатся через софт и контроль принятых стандартов в конкретной команде.

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

Плохо когда разработчик нарушает стиль кода принятый в команде или считает свой любимый (часто единственно выученный) стиль кода единственно правильным.

Не бывает правильных стилей кода. Бывают утвержденные стили в команде или общепринятые стили.

Тоже относительно простая проблема и легко решаемая.

Шизокод

Вот это менее популярная проблема, но часто наиболее дорогостоящая.

Шизокод — происходит от понятия шизофрении. Выжимка из Википедии:

Шизофрени́я (от др.-греч. σχίζω «расщеплять», «раскалывать» + φρήν — «ум, мышление, мысль»), ранее лат. dementia praecox («слабоумие преждевременное») или схизофрени́я — эндогенное полиморфное психическое расстройство или группа психических расстройств, связанное с распадом процессов мышления и эмоциональных реакций.

Тут 2 важных тезиса: раскалывание и слабоумие. Которые являются причинам шизокода.

Идеальный код — тот который не написан. Шизокодеры не знакомы с этим понятием.

Если коротко то шизокод, это код, который нарушает принцип Бритвы Оккама.

Выжимка из Википедии:

«Бритва (лезвие) О́ккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама. В упрощенном виде он гласит: «Не следует множить сущее без необходимости»

Выражается в том что разработчики начинают усложнять код и архитектуру без веских на то причин. Или вескость причин существует только в их воображении.

Есть 2 основных симптома: изобретение велосипедов на костылях и размножение слоев абстракции.

Изобретение велосипедов на костылях

Выражается в том что разработчики ввиду плохой способности обучаться вместо поиска оптимальных решений/методов в рамках платформы и существующей архитектуры начинают изобретать велосипеды/костыли.

• Написание своих CMS/фреймворков птм что у существующих есть фатальный недостаток
• Блог на Symfony. При том что весь мир для этого использует WordPress.
• Интернет-магазины на Laravel, при том что есть WooCommerce (№1 в мире), Magento (тоже хорошо), 1С-Битрикс (на худой конец, лучше чем Laravel)
• Встречал ситуацию когда верстка была на Bootstrap, но разработчик решил написать свои стили для меток (label). Что мешало добавить класс label, который уже есть в Bootstrap?
• Излишним функциям, методам и классам нет исчисления, которые можно было избежать используя уже готовые библиотеки и методы в используемых платформах

Бесконтрольное размножение слоев абстракции: лишние классы, наследования, методы

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

Тут нужно отметить что это одна из крайностей, границу которой не всегда просто соблюсти.

С одной стороны плохо все пытаться решать одной функцией на 3 страницы или класс который содержит в себе HTML и механики шаблона и где-то выгоднее разбить код на несколько функций/классов/компонентов, каждый из которых решает свою задачу. Это одна крайность.

С другой стороны плохо простой код разбивать на 5 классов в каждом из которых 3-4 метода по 3-4 строки, со множеством бесполезных наследований, когда можно обойтись одним или двумя с минимальным наследованием или даже без наследования если этого можно избежать.

Последствия лишних и плохих абстракций

Размножение методов, классов, наследований без веских причин — это лишний код и рост слоев абстракции.

У всего есть цена, как и у лишних абстракций:

• удоражается обучение новых разработчиков
• чем больше кода, тем больше точек отказа, тем больше ошибок
• усложняется диагностика и отладка кода

Проблема конечности мыслетоплива

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

А рабочий объем мыслетоплива конечен и часто его нехватка влечет очень большие затраты на разработку.

Каждый разработчик, который делал диагностику и изменение шизокода упирался в дефицит мыслетоплива. Но не все это осознавали.

Видео, в котором объясняется что такое мыслетопливо и дается простое упражнение на 1 минуту, которое позволяет вспомнить ощущение дефицита мыслетоплива на простом примере:

Это наезд на ООП, классы и наследование?

Отнюдь. Однако доля правды в этом есть. В функциональном стиле проще наговнокодить, но шизокодить там сложно. ООП же с одной стороны дает множество преимуществ, но и открывает простор для шизокода.

ООП, классы и наследование — это не плохо и не хорошо. Это инструменты. Я лично их использую.

Однако у меня есть ряд собственных правил:

• Классы пишу почти всегда из-за инкапсуляции, но часто мне хватает Синглтонов, статических методов и stateless
• Там где есть частоиспользуемый метод — пишу функции, которые часто являются лишь обертками для методов какого-либо класса, но иногда функция это просто функция без класса и это хорошо там где уместно.
• Классы stateful — да, но реже и опять же только там где есть веские причины
• Наследования еще реже, и только там где на то есть веские причины (стараюсь уменьшать слои абстракции и экономить мыслетопливо в команде)

Резюме

Мы много говорим о хардкоде и говнокоде т.к. они понятны и легко осязаемы. А вот шизокод часто остается безнаказанным, птм что его сложнее выявить и понять объем вреда от него. А объем вреда от него возможно больше чем можно представить с наскоку.

Мой манифест простой:

• лучше изучить принцип Best of breed, прежде чем изобрети очередной никому не нужный велосипед на костылях
• давайте писать меньше шизокода
• давайте учиться соблюдать принцип Бритвы Оккама и не усложнять код без причины
• давайте экономить свое мыслетопливо и своей команды

Ну и буду рад комментариям как в поддержку манифеста, так и его критике.

Что на самом деле нельзя хардкодить

Это страшное слово — хардкод. Все боятся это сделать, но иногда каждый из нас это делает.

Но я утверждаю, что хардкод в привычном нам понимании вовсе не так уж страшен, и на самом деле гораздо страшнее, когда в коде прописывают кое-что иное.

Так что же на самом деле нельзя хардкодить?

Классический хардкод

Все обычно считают, что

• Нельзя хардкодить числа в коде! Надо вынести в константу.
• Нельзя хардкодить настройки в коде! Надо вынести в файл с настройками (а у некоторых и в базу данных).

То есть если джуниор девелопер напишет в коде if (age >= 23) , ему за это надо дать по рукам. Так обычно считается. Чтобы сберечь руки, он должен срочно вынести “23” в константу типа MINIMUM_LOAN_AGE .

Давайте разбираться в причинах

А почему плохо прописать в коде “23”?

Обычно называют две причины. Их втирают нам в сознание ещё с университетской скамьи.

1. Когда нужно будет поменять “23” на “24”, её придётся поменять во многих файлах — трудоёмко.
2. Само по себе “23” плохо читается. Что означает “23” — возраст, длину волос, объём бензобака? Почему именно 23, а не 22 или 24?

Почему эти причины не катят?

Эти причины настолько нам привычны, что мы даже не задумываемся, насколько они актуальны в наше время. Вы удивитесь, но не очень-то актуальны. Прямо скажем, они устарели. Смотрите сами.

1. Во всех современных IDE очень легко поменять “23” на “24”. Одной кнопкой. Ctrl+R -> Enter. Всё. Хоть у тебя в проекте три файла, хоть три миллиона.
2. Да, “23” плохо читается. Но часто при вынесении в константу оно не становится более читаемым. Да, название константы MINIMUM_LOAN_AGE говорит о том, что это минимальный возраст, с которого можно брать кредит. Но и выражение if (age >= 23) в методе canRequestLoan() говорит ровно о том же ничуть не хуже.

А почему именно 23, почему не 22 или 24 — это всё равно непонятно. Чтобы это узнать, в наше время легче заглянуть в историю изменений (git -> annotate) или в тесты (Ctrl+Shift+T) — с нашими IDE это легко.

Ладно, ладно

Я знаю, вас переполняют эмоции. Вы хотели бы вбить мне в грудь осиновый кол за такую ересь. Но потерпите, сейчас мы дойдём до главного.

Конечно, всё-таки выносить такие штуки в константы иногда полезно.

Я хотел сказать, что самый страшный хардкод — это вовсе не константы.

А что же — самый страшный хардкод?

Вглядитесь внимательно в это выражение. Все обычно думают, что самый страшный хардкод — это вот:

Но вглядитесь, неужели это действительно самое страшное место? Оглядитесь вокруг, не притаилось ли рядом что-то более опасное? На самом деле самая страшная часть — это вот:

Потому, что вот её-то поменять во всём коде на порядок сложнее. Когда однажды выяснится, что для получения кредита нужно стать старше 23 лет, да ещё и найти работу, нам придётся найти в коде все места, где прописано if (age >= 23) и поменять их на if (age > 23 && employed) . Но как найти все знаки все знаки >= ? Их же тысячи! Вот это ручная работа на столетия!

Но самое страшное, что в коде могут быть и выражения вида

и даже такие места, которые совсем нереально обнаружить:

if (age  23)  // 100500 строк кода > else  // можно получить кредит > 

Что же делать?

Вот почему важно выносить не константы, а логику. Важно следить, чтобы любое знание в коде было прописано ровно в одном месте. В данном случае — знание о том, в каких случаях клиент может взять кредит (то самое >= 23 ) должно быть вынесено в отдельный метод.

class User  public boolean canRequestLoan()  return age >= 23; > > 

И все остальные места должны использовать этот метод. Кажется тривиальным? О нет. Если это знание действительно в одном месте, зачем вы так рьяно хотите вынести “23” в константу?

Упростим

Всё ещё кажется тривиальным? Ок, давайте упростим пример. Забудьте 23. Пусть будет 0.

Я уверен, в вашем коде миллион таких мест:

 if (account.balance > 0)  // могу сделать платёж > 

И я таких видел миллион. if balance > 0 прописан и на странице платежей, и на странице кредитов, и депозитов, и т.д.

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

 if (account.balance > 0 && !account.arrested)  // могу сделать платёж > 

Но тут… опачки. Оказывается, что в десяти местах прописано if (balance > 0) , в ещё двадцати — if (balance

И вот тут-то начинаются проблемы. Все эти места нужно анализировать отдельно. В некоторые из них нужно добавить && !arrested , а в некоторые не нужно — ведь там речь идёт не о платежах.

Я не придумываю, это абсолютно реальный пример.

Юнит-тесты

Очевидный плюс вынесения логики в методы — её легко тестировать.

Поначалу этот тест кажется даже избыточным и даже бесполезным:

 public class AccountTest  @Test public void canMakePaymentIfHasMoney()  assertTrue(new Account(1).canMakePayment()); assertFalse(new Account(-1).canMakePayment()); > > 

Но всё меняется, как только добавляются ньвые требования:

 public class AccountTest  @Test public void canMakePayment_ifHasMoney_and_notArrested()  assertTrue(new Account(1, false).canMakePayment()); > @Test public void cannotMakePaymentIfHasNoMoney()  assertFalse(new Account(-1, false).canMakePayment()); > @Test public void cannotMakePaymentIfArrested()  assertFalse(new Account(1, true).canMakePayment()); > > 

Пэдж обжекты

Всё ещё кажется, что для разумных людей это очевидные вещи?

Тогда посмотрите на пэдж обжекты — воплощение константного антипаттерна во всей красе! Миллионы людей выносят локаторы в константы и даже не задумываются, что что-то здесь не так…

Нормально ли так хардкодить значения в хранимой функции/приложении?

В зависимости от аргумента меняется значение для последующей вставки в таблицу. Или например храдкод в хранимой функции на обновление статуса:

IF status_id_in = 9 THEN --какие-то действия только в этом случаее ENDIF; --код 

Или вот пример хардкода серверной части приложения:

if elem.ExpireAt.After(time.Now()) < UpdateStatus(elem.ID, 45) return >value := someFunction() if value > elem.X< UpdateStatus(elem.ID, 32) >else

Мне кажется, что здесь правильно не ID статусов кидать, а уникальные имена, которые привязаны к нужному статусу (а потом, в хранимке брать ID по имени), но это же тоже храдкод? Есть ли решения лучше, чем использовать не ID , а имена? Или это не хардкод и такая связность нормальная?

Отслеживать
задан 13 авг 2021 в 18:17
Metamorphosis Metamorphosis
311 3 3 серебряных знака 10 10 бронзовых знаков

Ну а куда деваться, какой-то хардкод да будет. Но хорошо бы он был в каком-то справочнике, к которому бы обращались все процедуры.

13 авг 2021 в 18:33

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Я когда читаю этот код

IF argument_1 = 2 THEN value_to_insert = 32; ELSE value_to_insert = 1; END IF; --insert (. status_id) vaules (. value_to_insert) 

то у меня сразу возникают вопросы в его правильности. Почему именно эти значения? Что за логика реализована? А правильна ли она? Глядя на прошитые константы это все непонятно.

Гораздо лучше так:

IF action = BUY_ACTION THEN trade_status = BYING_STATUS; ELSE trade_status = SELLING_STATUS; END IF; --insert (. status_id) vaules (. trade_status) 

Именно с этой точки зрения хардкод констант это плохо. Если это реально константа, то она должна быть выражена константой в языке, если есть поддержка в языке (не знаю как в других, это подскажут, вероятно, но в pgplsql есть константы). Так чтоб один раз определить и использовать везде.

Если хранить эти значения в таблице, то:

1. это сбивает с толку, что и не константа это вовсе, а параметр конфигурации.
2. чтоб прочитать их — нужен отдельный запрос, что и по производительности хуже и код усложняется без хорошей причины