Чи є переваги жорсткого кодування значень даних у програмі?

Я самоучка, початківець кодер, тому прошу вибачення, якщо я не зафіксував мовою програміста.

Я працюю над проектом, в якому я надаю дані, які будуть постійно оновлюватися, розробникам, які по суті створять інструмент для генерування звітів із запитів на даних.

Здається, що всі учасники думають, що їм потрібно ввести жорсткі коди даних даних (не схеми, а самих доменів / значень) у програму генерації звітів.

Наприклад, припустимо, що ми звітували про персонал; звіт буде розділений на категорії, з заголовком для кожного відділу, а потім під кожним заголовком підрозділу будуть підзаголовки посадових назв, а потім під кожним підзаголовком буде список працівників. Розробники хочуть жорстко кодувати відділи та посади. З іншого боку, я думаю, що вони могли б / запитувати ці речі під час виконання, сортувати записи за ними та генерувати заголовки звітів динамічно на основі значень, які є.

Оскільки список потенційних значень з часом змінюватиметься (наприклад, створюватимуться / перейменовуватимуться відділи, додаватимуться нові заголовки завдань), код потрібно буде постійно оновлювати. Мені здається, ми могли пропустити кроки обслуговування коду та динамічно упорядкувати звіти.

Оскільки я не розробник, мені цікаво, чого мені не вистачає. Які переваги можуть мати жорстке кодування значень у такий інструмент? Як правило, як розроблені програми?

Вікіпедія:

Жорстке кодування (також жорстке кодування або жорстке кодування) стосується практики розробки програмного забезпечення вбудовування того, що, можливо, лише в ретроспективі, може вважатися вхідними або конфігураційними даними безпосередньо у вихідний код програми чи іншого виконуваного об'єкта, або фіксованим форматуванням дані, замість того, щоб отримувати ці дані із зовнішніх джерел або генерувати дані або форматувати в самій програмі із заданим входом.

Жорстке кодування вважається антипатерном.

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

Іноді цього не вдається уникнути, але це має бути тимчасово.

Часто потрібно жорстке кодування. Програмісти можуть не мати розробленого рішення для динамічного користувальницького інтерфейсу для кінцевого користувача, але все ж повинні надати функцію або випустити програму. Зазвичай це тимчасово, але в короткому терміні вирішує тиск для доставки коду. Пізніше робиться програмне кодування, щоб дозволити користувачеві передавати параметри, які дають кінцевому користувачеві спосіб змінити результати або результат.

• Жорстке кодування повідомлень ускладнює інтернаціоналізацію програми.
• Шляхи жорсткого кодування ускладнюють адаптацію до іншого місця.

Єдиною перевагою жорсткого кодування, здається, є швидка доставка коду.

Дійсно? Немає можливих дійсних випадків використання?

Хоча я погоджуюся, що жорстке кодування - це, як правило, антидіапазон або, принаймні, дуже поганий запах коду , є багато випадків, коли це має сенс:

• простота ( YAGNI ),
• вхід фактично постійний і ніколи не змінюватиметься (тобто являє собою природну чи ділову константу або наближення до одного. Наприклад, 0, PI, ...),
• вбудоване програмне забезпечення (пам'ятають про обмеження пам'яті та розподілу),
• захищене програмне забезпечення (ці значення не є доступними та / або простими для декодування чи реверсивної інженерії, наприклад, криптографічні маркери та солі),
• згенерований код (ваш препроцесор або генератор налаштовується, але випливає з жорстко кодованими значеннями),
• і, мабуть, ще кілька.

Все-таки анти-візерунок ? Так само і Over-Engineering ! Йдеться про тривалість життя вашого ПЗ !!

Не те, що я кажу, що для цього є всі великі причини, і я взагалі бідую за твердими значеннями. Але деякі можуть легко отримати пропуск з поважних причин.

І не слідкуйте за першим щодо простоти / YAGNI, не думаючи, що це тривіально: напевно, немає причин реалізувати шалений парсер і перевірку цінності для простого сценарію, який дуже добре виконує одну роботу для вузького використання.

Важко знайти баланс. Іноді ви не передбачаєте, що програмне забезпечення буде рости і тривати довше, ніж простий сценарій, який він запустив. Часто, проте, навпаки: ми надмірно розробляємо речі, і проект відкладається швидше, ніж ви можете прочитати Прагматичного програміста. Ви витратили час і сили на речі, ніж ранній прототип не потребував.

Це означає, що це стосується Anti-Patterns: вони присутні в обох крайніх межах спектру, і їх зовнішній вигляд залежить від чутливості людини, яка переглядає ваш код.

Значення жорсткого коду буває нормально. Наприклад, є деякі числа, такі як 0, або одне або різні n ^ 2-1 значення для бітових масок, які повинні бути певними значеннями для алгоритмічних цілей. Допуск таких значень до налаштування не має значення і лише відкриває можливість виникнення проблем. Іншими словами, якщо зміна значення лише порушить речі, це, мабуть, має бути жорстко закодовано.

У прикладі, який ви навели, я не бачу, де було б корисно жорстке кодування. Все, що ви згадуєте, / вже повинно бути в базі даних, включаючи заголовки. Навіть речі, які керують презентацією (наприклад, порядок сортування), можна додати, якщо їх там немає.

Реалізація надійного рішення, яке дозволяє для значень, які в іншому випадку могли бути жорстко закодовані, замість того, щоб їх можна було налаштувати кінцевим користувачам, вимагає надійної перевірки цих значень. Вони поставили в порожній рядок? Чи помістили вони щось нечислове, де воно повинно було бути числом? Вони роблять ін'єкцію SQL? І т.д.

Жорстке кодування дозволяє уникнути багатьох цих ризиків.

Що не означає, що жорстке кодування завжди, а то й часто, є гарною ідеєю. Це лише один із факторів, який слід враховувати.