it-swarm.com.de

Schlechte Praxis - Fall wechseln, um Umgebung einzustellen

In den letzten drei Jahren, in denen ich als Entwickler gearbeitet habe, habe ich viele Beispiele gesehen, bei denen Benutzer eine switch-Anweisung verwenden, um den Pfad (sowohl im Back-End als auch im Front-End) für eine URL festzulegen. Unten ist ein Beispiel dafür:

Backend-Beispiel (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;
}

Frontend-Beispiel (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/";
    }
})();

Es wurde diskutiert, ob es eine gute oder eine schlechte Praxis ist, und ich denke, es ist eine schlechte Praxis, weil wir diese Art von Code vermeiden und eine richtige Konfiguration festlegen müssen. Aber um ehrlich zu sein, weiß ich wirklich nicht die richtige Antwort und warum wird sie nicht empfohlen und wie kann man das richtig umsetzen?.

kann jemand die Vor- und Nachteile der oben genannten Praxis erklären?

32
gon250

Code, der für Sie funktioniert und einfach zu pflegen ist, ist per Definition "gut". Sie sollten niemals Dinge ändern, nur um der Idee einer "guten Praxis" zu gehorchen, wenn diese Person nicht darauf hinweisen kann, wo das Problem mit Ihrem Code liegt.

In diesem Fall besteht das offensichtlichste Problem darin, dass Ressourcen in Ihrer Anwendung fest codiert sind - selbst wenn sie dynamisch ausgewählt werden, sind sie immer noch fest codiert. Dies bedeutet, dass Sie diese Ressourcen nicht ändern können, ohne Ihre Anwendung neu zu kompilieren/bereitzustellen. Bei einer externen Konfigurationsdatei müssen Sie nur diese Datei ändern und Ihre Anwendung neu starten/laden.

Ob dies ein Problem ist oder nicht, hängt davon ab, was Sie damit machen. In einem Javascript-Framework, das ohnehin bei jeder Anforderung automatisch neu verteilt wird, ist dies überhaupt kein Problem. Der geänderte Wert wird bei der nächsten Verwendung der Anwendung an jeden Benutzer weitergegeben. Bei einer lokalen Bereitstellung in einer kompilierten Sprache an einem unzugänglichen Ort ist dies in der Tat ein sehr großes Problem. Die Neuinstallation der Anwendung kann lange dauern, viel Geld kosten oder nachts durchgeführt werden, um die Verfügbarkeit zu gewährleisten.

Ob fest codierte Werte ein Problem darstellen oder nicht, hängt davon ab, ob Ihre Situation eher dem ersten Beispiel oder eher dem zweiten Beispiel ähnelt.

81
Kilian Foth

Sie haben absolut Recht, wenn Sie denken, dass dies eine schlechte Praxis ist. Ich habe das im Produktionscode gesehen und es kommt immer wieder, um dich zu beißen.

Was passiert, wenn Sie eine weitere Umgebung hinzufügen möchten? Oder ändern Sie Ihren Entwicklungsserver? Oder müssen Sie an einen anderen Ort wechseln? Sie können nicht, weil Ihre Konfiguration direkt an Code gebunden ist.

Die Konfiguration sollte aus dem Code in die Umgebung selbst verschoben werden. Es ist ein Prinzip einer Zwölf-Faktoren-App ( http://12factor.net/config ), aber es ist eine gute Praxis für jede Anwendung. Möglicherweise sind Umgebungsvariablen für Ihre Situation nicht geeignet. In diesem Fall würde ich empfehlen, diese Konfiguration in einer Datenbank mit Konfigurationsdateien neben Code zu speichern, der jedoch nicht mit Code eingecheckt ist.

14
mgw854

Zum einen ist dies (wie bereits erwähnt) eine schlechte Idee, da Sie Implementierungsdetails in Ihren Code einbinden. Dies macht es schwierig, Dinge zu ändern.

Wie in diese Antwort erwähnt, müssen Sie, wenn Sie jetzt eine neue Umgebung hinzufügen möchten, Ihren Code überall aktualisieren, anstatt Fügen Sie einfach Ihr Programm einer neuen Umgebung hinzu.

Es gibt einen weiteren schwerwiegenden Fehler in Ihrem Javascript-Code: Sie setzen die Interna Ihres Unternehmens potenziellen Angreifern aus. Sicher, Sie befinden sich möglicherweise hinter einer Firewall, haben aber möglicherweise immer noch einen verärgerten Mitarbeiter oder jemanden, der einen Virus eindringt.

Schlechte Nachrichten Bären.

Das Beste , was Sie tun können, ist, Ihre Konfiguration über die Umgebung festzulegen (wie in der zuvor verknüpften Antwort hat die Twelve-Factor App gute Ratschläge zu diesem Thema). . Abhängig von Ihrer Sprache gibt es verschiedene Möglichkeiten, dies zu tun. Eine der einfachsten (normalerweise) ist das Festlegen von Umgebungsvariablen. Dann ändern Sie einfach die Variablen, je nachdem, wo Sie ausgeführt werden - ob es sich um eine lokale Entwicklungsbox, eine QA oder eine Produktion handelt. Eine andere Option ist das Speichern der Werte in einem .ini Datei oder JSON. Eine weitere Alternative wäre das Speichern Ihrer Konfigurationswerte als tatsächlicher Code. Je nachdem, welche Sprache oder Umgebung Sie verwenden, kann dies eine gute Idee sein oder auch nicht.

Das ultimative Ziel ist jedoch, dass Sie eine Codebasis verwenden, sie auf jedem Computer ablegen, der über die unterstützte Architektur/Konnektivität verfügt, und sie ausführen können ohne den Code in irgendeiner Weise zu ändern.

5
Wayne Werner

Was ist, wenn ich das Backend auf meinem eigenen Computer ausführen möchte, jedoch nicht auf Port 55793, z. B. wenn ich mehrere Versionen gleichzeitig ausgeführt habe, um sie zu vergleichen? Was ist, wenn ich das Anwendungs-Backend auf einem Computer ausführen, aber von einem anderen aus darauf zugreifen möchte? Was ist, wenn ich eine vierte Umgebung hinzufügen möchte? Wie andere bereits betont haben, müssen Sie neu kompilieren, um die Grundkonfiguration zu ändern.

Der von Ihnen beschriebene Ansatz hat möglicherweise bisher in der Praxis für Ihr Team funktioniert, ist jedoch sinnlos einschränkend. Ein Konfigurationssystem, mit dem Parameter wie dieser Pfad in einer zentralen Konfigurationsdatei beliebig festgelegt werden können, ist weitaus flexibler als eines, das nur feste Optionen bietet. Welchen Vorteil erzielen Sie mit dem Ansatz der switch-Anweisung? Keiner!

1
PeterAllenWebb

Es ist ein BAD PRACTICE.

Ein Grundprinzip des Software-Designs: Codieren Sie keine Konfigurationswerte in Ihren Programmen. Dies gilt insbesondere für alles, was eine vernünftige Chance hat, sich in Zukunft zu ändern.

Der von Ihnen entwickelte Programmcode sollte derselbe Code sein, der in alle Umgebungen wie QS-Tests, UAT und Produktion verwendet wird. Wenn jemand die Konfiguration später ändern muss, weil sich die Umgebung geändert hat, oder wenn er sie in einer neuen Umgebung verwenden muss, ist das in Ordnung. Sie sollten jedoch niemals Ihren Programmcode berühren müssen, um dies zu tun. Und Sie sollten nicht für jede Umgebung unterschiedliche Codeversionen haben. Wenn sich Ihr Programm seit dem Testen geändert hat, haben Sie diese Version nicht getestet. Fragen Sie einen Softwareentwickler, einen Experten für Softwarequalitätssicherung oder einen IT. Projektmanagement-Profi, jeder I.T. Wirtschaftsprüfer.

Jemand könnte das Testen auf einen anderen Server verschieben. Jemand könnte entscheiden, ob er auch eine Benutzerschulungsumgebung oder eine Umgebung für Verkaufsdemonstrationen möchte. Sie sollten für die administrative Konfiguration nicht zu einem Programmierer gehen müssen.

Software sollte flexibel und robust genug sein, um unerwartete Situationen im Rahmen des Zumutbaren zu bewältigen.

Darüber hinaus sollte Software nicht einfach geschrieben werden, sondern erscheint Ihnen im Moment am einfachsten. Die Kosten für die Softwareentwicklung sind im Vergleich zu den Kosten für die Softwarewartung über die gesamte Lebensdauer gering. Nehmen wir an, in einem Jahr sind Sie möglicherweise nicht die Person, die an diesem Code arbeitet. Sie sollten darüber nachdenken, was Sie für den nächsten armen Narren verlassen, der das Chaos auffangen muss, das Sie möglicherweise zurückgelassen haben, vielleicht Jahre nachdem Sie auf grünere Weiden gegangen sind. Oder Sie sind derjenige, der den Code Jahre später aufgreift und nicht glaubt, was Sie damals getan haben.

Codieren Sie die Dinge richtig, so gut Sie können. Es ist weniger wahrscheinlich, dass es später zu einem Problem wird.

0
WarrenT