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

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?

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.

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.

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.

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!

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.