Плохая практика - переключать дела, чтобы установить среду

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

Внутренний пример (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

Пример интерфейса (JavaScript):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

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

может кто-нибудь объяснить это плюсы и минусы вышеуказанной практики?

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

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

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

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

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

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

Конфигурация должна быть вытеснена из кода в саму среду. Это принцип приложения из двенадцати факторов ( http://12factor.net/config ), но это хорошая практика для любого приложения. Вы можете обнаружить, что переменные окружения не подходят для вашей ситуации, и в этом случае я бы посоветовал посмотреть на сохранение этой конфигурации в базе данных файла конфигурации вместе с (но не проверенным) кодом.

С одной стороны, (как уже упоминали другие) это плохая идея, потому что вы привязываете детали реализации к своему коду. Это затрудняет изменение вещей.

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

В вашем коде Javascript есть еще один серьезный недостаток: вы открываете внутренности вашей компании потенциальным злоумышленникам. Конечно, вы можете быть за брандмауэром, но у вас все еще может быть недовольный сотрудник или тот, кто пропускает вирус.

Плохие новости несут.

Лучше всего сделать , это установить конфигурацию из среды (как в ранее связанный ответе, Twelve-Factor App имеет большой совет по этой теме). Есть несколько способов сделать это в зависимости от вашего языка. Один из самых простых (обычно) - просто установить переменные окружения. Затем вы просто меняете переменные в зависимости от того, где вы работаете - будь то локальное устройство разработки, qa или production. Другим вариантом является сохранение значений в .iniфайле или JSON. Еще одна альтернатива будет хранить ваши значения конфигурации как фактический код. В зависимости от того, какой язык или среду вы используете, это может быть или не быть хорошей идеей.

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

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

Описанный вами подход, возможно, сработал на практике для вашей команды, но он бессмысленно ограничивает. Система конфигурации, которая позволяет произвольно устанавливать такие параметры, как этот путь, в центральном файле конфигурации, является гораздо более гибкой, чем система, которая предоставляет только фиксированные параметры, и какое преимущество вы получаете с подходом оператора switch? Никто!

Это плохая практика .

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

Код программы, который вы разрабатываете, должен быть тем же кодом, который входит в любую среду, такую ​​как QA-тестирование, UAT и производство. Если кому-то нужно изменить конфигурацию позже, потому что среда изменилась, или им нужно использовать ее в новой среде, хорошо. Но они никогда не должны трогать код вашей программы, чтобы сделать это. И у вас не должно быть разных версий кода для каждой среды. Если ваша программа изменилась с момента ее тестирования, значит, вы не тестировали эту версию. Спросите любого программиста, любого специалиста по обеспечению качества программного обеспечения, любого специалиста по управлению ИТ-проектами, любого ИТ-аудитора.

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

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

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

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