Лучшие практики для избежания жестко закодированных значений IRL

Question

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

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

Answer 1

Чтобы избежать жесткого кодирования, вы должны

• использовать файлы конфигурации (поместите ваши значения в XML или текстовые файлы, подобные ini).
• используйте таблицы базы данных для хранения ваших значений.

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

Только что увидел ответ, чтобы использовать «Constatn Interface». При всем уважении к афише и избирателям, но это не рекомендуется. Вы можете прочитать больше об этом на:

http://en.wikipedia.org/wiki/Constant_interface

Answer 2

Предположение, стоящее за этим вопросом, кажется мне неверным.

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

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

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

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

Answer 3

2 предложений здесь: во-первых, если вы работаете со встроенной системой на языке, подобном C. Просто разработайте соглашение о кодировании, чтобы использовать #define для любой строки или константы.Все #define должны быть классифицированы в файле .h.Этого должно быть достаточно - не слишком сложно, но достаточно для удобства обслуживания.Вам не нужно манипулировать всеми константами между строкой кода.

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

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

Answer 4

По общему признанию, я хранил много вещей в моем текущем хобби-проекте. Конфигурационные файлы невероятно просты в использовании (по крайней мере, с Python, который поставляется с отличным и простым парсером .cfg), я просто не потрудился использовать их, потому что на 99% уверен, что буду никогда не нужно их менять - и даже если это предположение окажется ложным, оно достаточно мало, чтобы реорганизовать его с разумными усилиями. Однако для чего-то большего / более важного я бы никогда не набрал if foo == "hardcoded bar", а скорее if foo == cfg.bar (вероятно, с более значимым именем для cfg). Cfg - это глобальный синглтон (да, я знаю ...), который загружается в файл .cfg при запуске, и в следующий раз, когда изменяется какое-то значение часового, вы изменяете файл конфигурации, а не источник.

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

Answer 5

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

Если у вашего проекта его нет, то либо:

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

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

Answer 6

Проблема жестко закодированных значений заключается в том, что иногда не является очевидным, что конкретный код опирается на них. Например, в Java можно переместить все константы в отдельный интерфейс и разделить отдельные константы во внутренние подчиненные интерфейсы. Это довольно удобно и очевидно. Также легко найти постоянное использование, просто используя средства IDE (функциональность «найти использование») и изменить или изменить их.

Вот пример:

public interface IConstants {

    public interface URL {
        String ALL = "/**";
    }

    public interface REST_URL {
        String DEBUG = "/debug";
        String SYSTEM = "/system";
        String GENERATE = "/generate";
    }
} 

Ссылка вполне понятна человеку: IConstants.REST_URL.SYSTEM

Answer 7

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