Есть ли преимущества для жесткого кодирования значений данных в программу?

13

Я самоучка, начинающий программист, поэтому я прошу прощения, если я не прибил программиста на жаргоне.

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

Кажется, что все участники думают, что им нужно жестко закодировать значения данных (не схему, а сами домены / значения) в программу генерации отчетов.

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

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

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

— Том
источник

1

возможный дубликат удаления жестко закодированных значений и защитного дизайна против YAGNI

— комнат

Являются ли отчеты кросс-таблицами, то есть значения в строках должны отображаться в виде столбцов?

— Тулаинс Кордова

1

@Brendan - если вы жестко кодируете значения в отчете, вам нужно изменить список в ДВУХ местах (источник данных и отчет), тогда как, если отчет динамический, вам нужно изменить его только в одном месте (отчет) ,

— Kwah

1

@ Брендан, почему у тебя в конечном итоге три места? Возможно, мое понимание неверно, но я предполагаю SQL-запрос для извлечения данных из базы данных, приложение будет собирать / группировать возвращаемые значения, например, по отделу. Если вы хотите получить накладные расходы на несколько запросов к базе данных, вы можете выбрать отдельные отделы / названия ролей, если вы действительно этого хотите. Ни в коем случае данные не существуют более чем в одном месте - отчет основывается на данных.

— Kwah

1

@ Брендан Я также не согласен с вашим определением того, что оно в одном месте - как вы описываете это в нескольких местах, разбросанных по всему исходному коду.

— Kwah

9

Википедия:

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

Жесткое кодирование считается антипаттерном.

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

Иногда вы не можете избежать этого, но это должно быть временным.

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

Жесткое кодирование сообщений затрудняет интернационализацию программы.
Пути жесткого кодирования затрудняют адаптацию к другому месту.

Единственное преимущество жесткого кодирования - быстрая доставка кода.

— Тулаинс Кордова
источник

5

Хорошо, но «единственное преимущество» часто чрезвычайно важно. Проектные решения в программировании часто сводятся к компромиссу между проверкой будущего и быстрой доставкой сейчас, и поэтому жесткое кодирование может быть вполне приемлемым выбором. Иногда не сложное кодирование - плохой выбор дизайна.

-1 Не думаю, что это полезный ответ. По сути, это говорит о том, что «встраивание значений в исходный код не по назначению» неуместно. Я думаю, что ОП хочет руководство о том, когда вещи могут принадлежать исходному коду и, следовательно, выходить за рамки вашего определения в Википедии.

— Натан Купер

Жесткое кодирование должно быть жизненно важной частью вашего процесса, и, учитывая его, антипаттерн устарел в эпоху микросервисов, а учебник Angular Tour of Heroes является ярким примером огромного программного обеспечения, напрямую кодирующего или даже предписывающего промежуточный шаг. Более того, когда вы переходите к динамическим данным, вы все равно должны сохранять некоторые жестко закодированные данные в качестве запасного варианта, возможно, контролируемого переменной среды или даже логическим переключением на самом коде, чтобы ошибки и проблемы безопасности можно было должным образом изолировать на линия.

— Что в поиске Google

24

В самом деле? Нет возможных допустимых случаев использования?

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

простота ( ЯГНИ ),
входные данные на самом деле постоянны и никогда не изменятся (т.е. они представляют собой натуральную или бизнес-константу или приблизительную единицу. Например, 0, PI, ...),
встроенное программное обеспечение (на ум приходят ограничения памяти и распределения),
защищенное программное обеспечение (эти значения недоступны и / или не могут быть легко декодированы или реконструированы, например, криптографические токены и соли),
сгенерированный код (ваш препроцессор или генератор настраивается, но выдает код с жестко заданными значениями),
и, вероятно, еще несколько.

Все еще анти-паттерн ? Так что Over-Engineering ! Это о продолжительности жизни вашего программного обеспечения!

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

И не стоит упускать из виду первый, касающийся простоты / YAGNI , думая, что это тривиально: вероятно, нет смысла реализовывать сумасшедший анализатор и средство проверки значений для простого сценария, который очень хорошо выполняет одну работу для узкого варианта использования.

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

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

— haylem
источник

Это забавно, потому что я пилотировал это сам, и мне было намного проще, быстрее и чище динамически обрабатывать значения. Я сделал это на Python, хотя я считаю, что конечный продукт будет написан на Java - если это что-то изменит. Когда я жестко запрограммировал значения, это казалось чрезмерно сложным, потому что каждый входящий столбец нужно было отслеживать в нескольких местах.

— Том

@Tom: Вы говорите, что было проще и быстрее реализовать (или даже повторно) использовать библиотеку поиска конфигурации, чем использовать жестко запрограммированное значение? Отлично для тебя. Кроме того, я не понимаю, как ваше последнее предложение соответствует определению чрезмерной инженерии. Это было бы явно беспорядочно, и, очевидно, если оно жестко запрограммировано и дублировано, это еще хуже (что не было вопросом вашего вопроса, я, вероятно, неправильно понял, но мне показалось, что вы имели в виду, что значение не было жестко закодировано каждый раз, но в одной точке программы).

— Хайлем

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

— Хайлем

1

@ Том, не продавай себя слишком коротко. Вы определенно на что-то. Звучит проще и меньше времени, чтобы написать быстрый алгоритм организации данных, взглянув на поля Department и Job Title, а не на жесткое кодирование Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Также было бы гораздо сложнее поддерживать массив с жестким кодом в случае введения нового отдела или названия.

— Крис Г

1

Вы можете иметь более сложные вещи, которые все еще чувствительны к жесткому коду. Тот, который приходит на ум, что я написал несколько лет назад, был всеми возможными перестановками набора значений. Мне нужно было найти случайное правильное направление, выбрать случайную перестановку и затем взять первый действительный результат, безусловно, самое эффективное решение, и поскольку оно было в цикле O (N ^ 3), эффективность имела значение.

— Лорен Печтел

4

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

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

— JimmyJames
источник

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

— Том

1

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

— JimmyJames

-1

Реализация надежного решения, которое учитывает значения, которые в противном случае могли бы быть жестко запрограммированы, вместо того чтобы конфигурироваться конечными пользователями, требует надежной проверки этих значений. Они вставили пустую строку? Они вставили что-то не числовое, где это должно было быть число? Они делают инъекцию SQL? И т.п.

Жесткое кодирование позволяет избежать многих из этих рисков.

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

— Тофер Элиот
источник