Zła praktyka - zmień obudowę, aby ustawić środowisko

32

W ciągu ostatnich trzech lat, kiedy pracowałem jako programista, widziałem wiele przykładów, w których ludzie używają instrukcji switch do ustawiania ścieżki (zarówno wewnętrznej, jak i front-endowej) adresu URL. Poniżej znajduje się przykład tego:

Przykład zaplecza (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;
}

Przykład frontonu (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/";
    }
})();

Omówiono, czy jest to dobra czy zła praktyka, i myślę, że jest to zła praktyka, ponieważ musimy unikać tego rodzaju kodu i ustawić odpowiednią konfigurację. Ale szczerze mówiąc, naprawdę nie znam właściwej odpowiedzi i dlaczego nie jest to zalecane i jaki jest właściwy sposób realizacji tego.

czy ktoś może wyjaśnić zalety i wady powyższej praktyki?

— gon250
źródło

13

Sama linia nie jest optymalna. ścieżka = „ twojapath.com ”; Konfiguracja powinna być zewnętrzna względem kodu.

— paparazzo

2

Z czystego punktu widzenia przegląd kodu Dictionaryjest znacznie prostszym sposobem kodowania tego w języku C #. Zobacz ideone.com/45g5xO . Lub w JS użyj starego, dobrego obiektu, patrz jsfiddle.net/1ouhovqq .

— Danny Beckett,

4

co się stanie, jeśli nazwa Twojej firmy zmieni się na coś, co zawiera „qa”?

— user253751,

Pamiętaj, że jeśli używasz pliku konfiguracyjnego, musi on być kontrolowany przy pomocy kontroli kodu źródłowego ... Każda konfiguracja nowych maszyn testowych może wymagać edycji pliku konfiguracyjnego wiele razy dziennie. Nadal uważam, że plik konfiguracyjny jest najlepszy, ale możesz najpierw poszukać pliku o nazwie Środowisko, zanim przejrzysz szczegółowy plik konfiguracyjny.

— Ian

1

Nie sądzę, że powinieneś nazywać rzeczy złymi praktykami, jeśli nie potrafisz określić, dlaczego uważasz to za złą praktykę

— Roy

81

Kod, który działa dla Ciebie i jest łatwy w utrzymaniu, jest z definicji „dobry”. Nigdy nie powinieneś zmieniać rzeczy tylko po to, aby być posłusznym czyjejś idei „dobrej praktyki”, jeśli ta osoba nie jest w stanie wskazać, na czym polega problem z twoim kodem.

W tym przypadku najbardziej oczywistym problemem jest to, że zasoby są zakodowane na stałe w Twojej aplikacji - nawet jeśli są wybierane dynamicznie, nadal są zakodowane na stałe. Oznacza to, że nie można zmienić tych zasobów bez ponownej kompilacji / ponownego wdrożenia aplikacji. W przypadku zewnętrznego pliku konfiguracyjnego wystarczy zmienić ten plik i ponownie uruchomić / ponownie załadować aplikację.

To, czy jest to problem, zależy od tego, co z nim zrobisz. W frameworku JavaScript, który i tak jest automatycznie redystrybuowany przy każdym żądaniu, nie stanowi to żadnego problemu - zmieniona wartość zostanie rozpowszechniona dla każdego użytkownika przy następnym użyciu aplikacji. Przy wdrożeniu lokalnym w skompilowanym języku w niedostępnej lokalizacji jest to naprawdę bardzo duży problem. Ponowna instalacja aplikacji może zająć dużo czasu, kosztować dużo pieniędzy lub musi zostać wykonana w nocy, aby zachować dostępność.

To, czy wartości zakodowane na stałe stanowią problem, zależy od tego, czy twoja sytuacja bardziej przypomina pierwszy przykład, czy bardziej jak drugi przykład.

— Kilian Foth
źródło

15

Uwielbiam twój pierwszy akapit. Jasne, że kontynuujesz ... zwracając uwagę na problemy ... ale pomysł, że „to źle, bo tak napisał blog XYZ”, jest przyczyną więcej złego kodu, niż w rzeczywistości zapobiega.

— corsiKa,

5

Początkującym należy dać czas sprawdzone zasady, według których można żyć, a nie tylko „jeśli to działa dla ciebie, to jest w porządku” relatywizm. Wydaje mi się, że nie mylę się, twierdząc, że twarde kodowanie wartości środowiska jest wręcz złą praktyką pod każdym względem.

— Tulains Córdova,

3

@ jpmc26: Zakładasz oczywiście, że wdrożenie kodu po stronie serwera nie jest trywialne, a także że istnieje pewien osobny proces, za pomocą którego wartości konfiguracyjne mogą być aktualizowane przy mniejszym obciążeniu. Nie zawsze jest to prawda. Wiele sklepów ma bardzo małe koszty ogólne w procesach wdrażania. Z drugiej strony istnieją sklepy, w których zmiany konfiguracji mają zasadniczo tyle samo narzutów co wdrażanie zmienionego kodu. (Walidacja, wymagająca zatwierdzenia przez całą grupę ludzi itp.). Obawy dotyczące powielania są jednak zdecydowanie aktualne.

— Kevin Cathcart,

2

Po zmieszaniu ustawień środowiska z kodem aplikacji masz jeden błąd logiczny - lub nieprzewidzianą zmianę w środowisku wykonawczym - od trafienia testu z produkcji lub produkcji z testu lub jakiejś innej nieoczekiwanej i prawdopodobnie katastrofalnej kombinacji. Utrzymywanie właściwości specyficznych dla środowiska oddzielnie od kodu w języku C # jest na ogół trywialne. Po co podejmować niepotrzebne ryzyko?

— John M. Gant,

1

@ user61852 „Wydaje mi się, że nie mylę się, twierdząc, że twarde kodowanie wartości środowiska jest absolutnie złą praktyką pod żadnym pozorem”. parsuje do „wartości środowiska kodowania na stałe to zawsze zła praktyka” Jeśli jest to zawsze praktyka zła, zawsze powinna istnieć możliwość zidentyfikowania co najmniej jednego problemu, który spowodują wartości środowiska kodowania na stałe.

— emory,

14

Masz całkowitą rację, sądząc, że to zła praktyka. Widziałem to w kodzie produkcyjnym i zawsze wraca, by cię ugryźć.

Co się stanie, gdy chcesz dodać inne środowisko? Lub zmienić swój serwer programowania? A może potrzebujesz przełączenia awaryjnego do innej lokalizacji? Nie możesz, ponieważ twoja konfiguracja jest bezpośrednio związana z kodem.

Konfiguracja powinna zostać wymuszona z kodu i do samego środowiska. Jest to zasada aplikacji dwunastoczynnikowej ( http://12factor.net/config ), ale jest to dobra praktyka dla każdej aplikacji. Może się okazać, że zmienne środowiskowe nie są odpowiednie dla twojej sytuacji, w takim przypadku sugeruję przechowywanie tej konfiguracji w bazie danych pliku konfiguracyjnego wraz z (ale nie zalogowanym) kodem.

— mgw854
źródło

Jeśli nie śledzisz pliku konfiguracyjnego, skąd wiesz, czy posiadany plik konfiguracyjny jest ważny dla wersji oprogramowania, którą właśnie wypisałeś z VCS. (tzn. nieśledzony plik konfiguracyjny nie różni się od nieśledzonego pliku źródłowego - bez niego nie można zbudować i wdrożyć z kasy VCS)

— mattnz

Nie zgadzam się, że nieśledzony plik konfiguracyjny jest trudną propozycją. Sposób, w jaki wcześniej sobie z tym poradziłem, jest dwojaki: po pierwsze, plik binarny do wdrożenia zawiera również schemat XML definiujący jego konfigurację (abyś mógł sprawdzić, czy dany plik konfiguracyjny będzie działał). Po drugie, pliki konfiguracyjne dla każdego środowiska były przechowywane w systemie kontroli dokumentów z różnymi folderami dla każdego środowiska. Coś podobnego można zrobić w Git z gałęziami - kontrolowanymi wersjami, ale w odróżnieniu od kodu bez środowiska.

— mgw854

5

Po pierwsze (jak wspomnieli inni) jest to zły pomysł, ponieważ łączysz szczegóły implementacji z kodem. Utrudnia to zmianę rzeczy.

Jak wspomniano w tej odpowiedzi , jeśli chcesz dodać nowe środowisko, musisz teraz zaktualizować kod wszędzie , zamiast dodawać program do nowego środowiska.

Jest jeszcze jeden poważny błąd związany z robieniem tego w kodzie JavaScript: narażasz elementy wewnętrzne swojej firmy na potencjalne ataki. Oczywiście możesz znajdować się za zaporą ogniową, ale nadal możesz mieć niezadowolonego pracownika lub kogoś, kto wpuszcza wirusa.

Złe wieści.

Najlepszą rzeczą do zrobienia jest, aby ustawić konfigurację z otoczenia (jak w poprzednio połączonego odpowiedź Dwunastu-Factor App ma świetne porady na ten temat). Można to zrobić na kilka sposobów w zależności od języka. Jednym z najłatwiejszych (zwykle) jest po prostu ustawienie zmiennych środowiskowych. Następnie po prostu zmieniasz zmienne w zależności od tego, gdzie działasz - niezależnie od tego, czy jest to lokalne okno deweloperów, qa, czy produkcja. Inną opcją jest przechowywanie wartości w .inipliku lub JSON. Jeszcze inną alternatywą byłoby przechowywanie wartości konfiguracji jako rzeczywistego kodu. W zależności od używanego języka lub środowiska może to być dobry pomysł.

Ostatecznym celem jest jednak umożliwienie skorzystania z jednej bazy kodu, upuszczenia go na dowolnym komputerze z obsługiwaną architekturą / łącznością i umożliwienia uruchomienia go bez modyfikowania kodu w jakikolwiek sposób.

— Wayne Werner
źródło

1

Co jeśli chcę uruchomić backend na moim własnym komputerze, ale nie na porcie 55793, na przykład, jeśli korzystałem z wielu wersji jednocześnie, aby je porównać? Co jeśli chcę uruchomić backend aplikacji na jednym komputerze, ale uzyskać do niego dostęp z innego? Co jeśli chcę dodać czwarte środowisko? Jak zauważyli inni, musisz ponownie skompilować, aby zmienić podstawową konfigurację.

Podejście, które opisałeś, mogło do tej pory zadziałać w praktyce dla twojego zespołu, ale jest bezcelowe. System konfiguracji, który pozwala na dowolne ustawianie parametrów takich jak ta ścieżka w centralnym pliku konfiguracyjnym, jest znacznie bardziej elastyczny niż ten, który zapewnia tylko stałe opcje, i jaką korzyść zyskujesz dzięki podejściu instrukcji switch? Żaden!

— PeterAllenWebb
źródło

0

To ZŁA PRAKTYKA .

Podstawowa zasada projektowania oprogramowania: nie zapisuj na stałe wartości konfiguracyjnych w swoich programach. Dotyczy to szczególnie wszystkiego, co ma rozsądną szansę na zmianę w przyszłości.

Opracowany przez Ciebie kod programu powinien być tym samym kodem, który trafia do dowolnego środowiska, takiego jak testowanie jakości, UAT i produkcja. Jeśli ktoś musi później zmienić konfigurację, ponieważ zmieniło się środowisko, lub musi go użyć w nowym środowisku, dobrze. Ale nigdy nie powinny dotykać kodu programu, aby to zrobić. I nie powinieneś mieć różnych wersji kodu dla każdego środowiska. Jeśli Twój program zmienił się od czasu jego przetestowania, to nie przetestowałeś tej wersji. Zapytaj dowolnego inżyniera oprogramowania, każdego specjalistę ds. Zapewnienia jakości oprogramowania, każdego specjalistę ds. Zarządzania projektami IT, każdego audytora IT.

Ktoś może przenieść testowanie na inny serwer. Ktoś może zdecydować, że chce także środowisko szkolenia użytkowników lub środowisko do prezentacji sprzedaży. Nie powinni iść do programisty w celu konfiguracji administracyjnej.

Oprogramowanie powinno być wystarczająco elastyczne i solidne, aby poradzić sobie z nieoczekiwanymi sytuacjami, z uzasadnionego powodu.

Co więcej, oprogramowanie nie powinno być pisane po prostu, jednak wydaje się obecnie najłatwiejsze. Koszt opracowania oprogramowania jest niewielki w porównaniu z kosztami utrzymania oprogramowania przez cały okres jego użytkowania. Powiedzmy, że za rok może nie być osobą pracującą nad tym kodem. Powinieneś pomyśleć o tym, co zostawiasz dla następnego biednego głupca, który musi podnieść bałagan, który pozostawiłeś za sobą, być może lata po przejściu na zielone pastwiska. Albo możesz być tym, który lata później odbiera kod, nie wierząc w to, co wtedy robiłeś.

Koduj poprawnie, najlepiej jak potrafisz. Jest mniej prawdopodobne, że stanie się później problemem.

— WarrenT
źródło