Погана практика - переключити корпус на встановлене середовище


32

В останні три роки, коли я працював розробником, я бачив безліч прикладів, коли люди використовують оператор перемикання, щоб встановити шлях (як у зворотному, так і в передньому) для 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/";
    }
})();

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

може хтось пояснить це плюси і мінуси вищезазначеної практики?


13
Сама по собі ця лінія не є оптимальною. path = " yourpath.com "; Конфігурація повинна бути зовнішньою для коду.
папараццо

2
З точки зору чистого перегляду коду, a Dictionaryє набагато більш чистим способом кодування цього тексту в C #. Дивіться ideone.com/45g5xO . Або в JS використовуйте старий добрий об'єкт, див. Jsfiddle.net/1ouhovqq .
Danny Beckett

4
що станеться, якщо назва вашої компанії зміниться на щось, що містить "qa"?
користувач253751

Пам’ятайте, що якщо ви використовуєте конфігураційний файл, його потрібно контролювати у контролі вихідного коду .... Будь-який, можливо, доведеться редагувати конфігураційний файл багато разів на день під час налаштування нових тестових машин. Я все ще думаю, що найкраще налаштований файл конфігурації, але ви, можливо, спершу шукаєте файл із назвою Environment, перш ніж переглянути файл конфігурації detaul.
Ян

1
Я не думаю, що вам слід обійтися поганою практикою, якщо ви не можете оцінити, чому ви вважаєте, що це погана практика
Рой

Відповіді:


81

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

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

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

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


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

5
Початківцям слід дати перевірені часом принципи, щоб жити, а не просто "якщо це працює для вас, то це нормально", релятивізм. Я думаю, я не помиляюся, що твердження, що жорстке кодування в середовищі - це погана практика при будь-якому світлі.
Tulains Córdova

3
@ jpmc26: Ви, звичайно, припускаєте, що розгортання коду сторони сервера нетривіально, а також, що існує якийсь окремий процес, завдяки якому значення конфігурації можна оновлювати з меншими накладними витратами. І це не обов'язково правда. Багато магазинів мають дуже невеликі накладні витрати в процесі розгортання. З іншого боку, насправді є деякі магазини, де зміни конфігурації мають в основному стільки ж витрат, скільки розгортання зміненого коду. (Валідація, потребує схвалення цілої групи людей тощо). Проблеми щодо дублювання, безумовно, справедливі.
Кевін Кеткарт

2
З налаштуваннями середовища, змішаними з кодом програми, ви маєте одну логічну помилку - або непередбачувану зміну середовища виконання - від удару проби від виробництва, виготовлення з тесту чи іншої несподіваної та, можливо, катастрофічної комбінації. Збереження властивостей, пов'язаних з довкіллям, окремо від коду в C #, як правило, тривіально. Навіщо ризикувати зайвим?
Джон М Гант

1
@ user61852 "Напевно, я не помиляюся, сказавши, що значення середовища жорсткого кодування - це погана практика за будь-якого світла". синтаксичний аналіз на "значення середовища жорсткого кодування - це завжди погана практика". Якщо це завжди погана практика, то завжди має бути можливість виявити принаймні одну проблему, яку спричинить значення середовища жорсткого кодування.
emory

14

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

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

Конфігурація повинна витіснятися з коду і в саме середовище. Це принцип дванадцятифакторного додатка ( http://12factor.net/config ), але це хороша практика для будь-якого додатка. Ви можете виявити, що змінні середовища не підходять для вашої ситуації, і в такому випадку я б запропонував поглянути на збереження цієї конфігурації у базі даних файлу конфігурації поряд (але не зареєстрованого з) кодом.


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

Я не погоджуюся з тим, що файл без конфігурації, що не відслідковується, є важкою пропозицією. Спосіб, яким я займався цим раніше, є дворазовим: одне, двійковий код для розгортання також містить XML-схему, що визначає його конфігурацію (так що ви можете перевірити, чи буде працювати певний файл конфігурації). По-друге, файли конфігурації для кожного середовища зберігалися в системі управління документами з різними папками для кожного середовища. Щось подібне можна було б зробити в Git із гілками - керованою версією, але дискримінацією коду, що не стосується середовища.
mgw854

5

Для одного (як уже згадували інші) це погана ідея, оскільки ви вказуєте деталі реалізації у свій код. Це ускладнює зміни речей.

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

Є ще один серйозний недолік у виконанні цього коду у вашому Javascript: Ви піддаєте внутрішніх ресурсів своєї компанії потенційних зловмисників. Звичайно, ви можете бути за брандмауером, але у вас все ще може бути незадоволений працівник або хтось, хто пускає вірус.

Погані новини несуть.

Краще всього зробити , це встановити конфігурацію з середовища (як в раніше пов'язаний відповіді, Twelve-Factor App має велику раду по цій темі). Існує кілька способів зробити це залежно від вашої мови. Одне з найпростіших (як правило) - це просто встановити змінні середовища. Тоді ви просто змінюєте змінні в залежності від того, де ви працюєте - чи це локальне поле для розробників, qa, чи виробництво. Інший варіант - збереження значень у .iniфайлі або JSON. Ще одна альтернатива - це збереження ваших значень конфігурації як фактичного коду. Залежно від того, якою мовою чи середовищем ви користуєтесь, це може бути, а може і не бути хорошою ідеєю.

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


1

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

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


0

Це БАГА ПРАКТИКА .

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

Розроблений вами програмний код повинен бути тим самим кодом, який потрапляє в будь-яке середовище, наприклад тестування якості, UAT та виробництво. Якщо комусь потрібно пізніше змінити конфігурацію, оскільки змінилося середовище або їм потрібно використовувати його в новому середовищі, добре. Але вони ніколи не повинні торкатися коду програми для цього. І у вас не повинно бути різних версій коду для кожного середовища. Якщо ваша програма змінилася після її тестування, ви не перевірили цю версію. Запитайте будь-якого інженера-програмного забезпечення, будь-якого професіонала із забезпечення якості програмного забезпечення, будь-якого професіонала управління ІТ-проектами, будь-якого ІТ-аудитора.

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

Програмне забезпечення повинно бути гнучким і надійним, щоб вирішити несподівані ситуації, в межах причини.

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

Кодуйте речі належним чином, як тільки можете. Пізніше це стане проблемою.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.