Mauvaise pratique - changer de cas pour définir l'environnement


32

Au cours des trois dernières années où j'ai travaillé en tant que développeur, j'ai vu beaucoup d'exemples dans lesquels des personnes utilisent une instruction switch pour définir le chemin d'accès (à la fois en back-end et en front-end) pour une URL. En voici un exemple:

Exemple de back-end (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;
}

Exemple frontal (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/";
    }
})();

Nous avons discuté de la question de savoir si c'est une bonne ou une mauvaise pratique, et je pense que c'est une mauvaise pratique, car nous devons éviter ce type de code et définir une configuration appropriée. Mais pour être honnête, je ne connais vraiment pas la bonne réponse, et pourquoi n’est-elle pas recommandée et quelle est la bonne façon de la mettre en œuvre?

quelqu'un peut-il expliquer les avantages et les inconvénients de la pratique ci-dessus?


13
Cette ligne seule n'est pas optimale. path = " yourpath.com "; La configuration doit être externe au code.
paparazzo

2
Du point de vue de la révision de code pure, a Dictionaryest un moyen beaucoup plus simple de coder cela en C #. Voir ideone.com/45g5xO . Ou, dans JS, utilisez un bon vieux objet, voir jsfiddle.net/1ouhovqq .
Danny Beckett

4
que se passe-t-il si le nom de votre entreprise change en un élément contenant "qa"?
user253751

N'oubliez pas que si vous utilisez un fichier de configuration, il doit être contrôlé dans le contrôle de code source .... Vous devrez peut-être éditer le fichier de configuration plusieurs fois par jour lors de la configuration de nouveaux ordinateurs de test. Je pense toujours qu’un fichier de configuration est préférable, mais vous voudrez peut-être tout d’abord rechercher un fichier nommé Environnement basé avant de regarder le fichier de configuration detaul.
Ian

1
Je ne pense pas que vous devriez
Roy

Réponses:


81

Un code qui fonctionne pour vous et qui est facile à maintenir est par définition "bon". Vous ne devriez jamais changer les choses simplement pour obéir à l'idée de "bonne pratique" de quelqu'un si cette personne ne peut pas dire quel est le problème avec votre code.

Dans ce cas, le problème le plus évident est que les ressources sont codées en dur dans votre application. Même si elles sont sélectionnées de manière dynamique, elles le sont toujours. Cela signifie que vous ne pouvez pas modifier ces ressources sans recompiler / redéployer votre application. Avec un fichier de configuration externe, il vous suffirait de modifier ce fichier et de redémarrer / recharger votre application.

Que ce soit un problème ou non dépend de ce que vous en faites. Dans un framework Javascript qui est de toute façon automatiquement redistribué à chaque requête, ce n'est pas un problème - la valeur modifiée sera propagée à chaque utilisateur lors de la prochaine utilisation de l'application. Avec un déploiement sur site dans un langage compilé dans un endroit inaccessible, c'est un très gros problème. La réinstallation de l'application peut prendre beaucoup de temps, coûter beaucoup d'argent ou être effectuée de nuit pour préserver la disponibilité.

Que les valeurs codées en dur soient ou non un problème dépend de si votre situation ressemble davantage au premier exemple ou plus au deuxième exemple.


15
J'aime votre premier paragraphe. Bien sûr, vous continuez avec ... en soulignant quels sont les problèmes ... mais l'idée que "c'est mauvais parce que le blog XYZ l'a dit" est la cause de plus de mauvais code qu'il n'en empêche réellement.
CorsiKa

5
Il faut donner aux débutants des principes éprouvés, et pas simplement "si cela fonctionne pour vous, alors c'est OK" relativisme. Je suppose que je n’ai pas tort de dire que les valeurs d’environnement codées en dur sont carrément une mauvaise pratique.
Tulains Córdova

3
@ jpmc26: Vous supposez bien sûr que le déploiement du code côté serveur n'est pas trivial et qu'il existe un processus séparé permettant de mettre à jour les valeurs de configuration avec moins de temps système. Ni est nécessairement vrai. De nombreux magasins ont très peu de temps système dans leurs processus de déploiement. De l’autre côté, dans certains magasins, les modifications de configuration entraînent généralement autant de frais généraux que le déploiement de code modifié. (Validation, nécessitant l'approbation de tout un groupe de personnes, etc.). Les problèmes de duplication sont définitivement valables cependant.
Kevin Cathcart

2
Avec les paramètres d’environnement mélangés au code de votre application, vous êtes l’une des erreurs de logique - ou une modification imprévue de l’environnement d’exécution - qui empêche de passer d’un test à l’autre, d’une production à l’autre ou d’une combinaison inattendue, voire catastrophique. Conserver des propriétés spécifiques à l’environnement séparément du code en C # est généralement trivial. Pourquoi prendre un risque inutile?
John M Gant

1
@ user61852 "Je suppose que je n'ai pas tort de dire que les valeurs d'environnement de codage en dur sont carrément une mauvaise pratique, à tout point de vue." analyse comme "les valeurs d'environnement de codage en dur est toujours une mauvaise pratique" Si cela est toujours le cas, il devrait toujours être possible d'identifier au moins un problème que les valeurs d'environnement de codage en dur poseront.
emory

14

Vous avez absolument raison de penser que c'est une mauvaise pratique. J'ai vu cela dans le code de production, et cela revient toujours à vous mordre.

Que se passe-t-il lorsque vous souhaitez ajouter un autre environnement? Ou changez votre serveur de développement? Ou vous avez besoin de basculer vers un autre emplacement? Vous ne pouvez pas parce que votre configuration est directement liée au code.

La configuration doit être forcée hors du code et dans l'environnement lui-même. C'est le principe d'une application Twelve-Factor ( http://12factor.net/config ), mais c'est une bonne pratique pour toute application. Vous constaterez peut-être que les variables d'environnement ne sont pas adaptées à votre situation. Dans ce cas, nous vous suggérons de stocker cette configuration dans une base de données de fichiers de configuration à côté (mais pas avec le code) du code.


Si vous ne suivez pas le fichier de configuration, comment savoir si le fichier de configuration que vous avez est valide pour la version du logiciel que vous venez d'extraire de votre VCS. (c.-à-d. qu'un fichier de configuration non suivi n'est pas différent d'un fichier source non suivi - vous ne pouvez pas construire et déployer à partir de la commande VCS sans cela)
mattnz

Je ne suis pas en désaccord avec le fait qu'un fichier de configuration non suivi est une proposition difficile. La façon dont j'ai déjà traité cette question est double: premièrement, le fichier binaire pour le déploiement contient également un schéma XML définissant sa configuration (vous pouvez ainsi vérifier qu'un fichier de configuration donné fonctionnera). Deuxièmement, les fichiers de configuration de chaque environnement ont été stockés dans un système de contrôle de document avec des dossiers différents pour chaque environnement. Quelque chose de similaire pourrait être fait dans Git avec des branches - version contrôlée, mais différenciée du code sans environnement.
mgw854

5

D'une part, (comme d'autres l'ont mentionné), c'est une mauvaise idée car vous attachez des détails d'implémentation à votre code. Cela rend difficile de changer les choses.

Comme indiqué dans cette réponse , si vous souhaitez ajouter un nouvel environnement, vous devez mettre à jour votre code partout , au lieu d’ajouter votre programme à un nouvel environnement.

Cela comporte un autre défaut grave dans votre code Javascript: vous exposez les éléments internes de votre entreprise à des attaquants potentiels. Bien sûr, vous êtes peut-être derrière un pare-feu, mais vous pouvez toujours avoir un employé mécontent ou quelqu'un qui laisse entrer un virus.

Mauvaise nouvelle ours.

La meilleure chose à faire est de définir votre configuration à partir de l'environnement (comme dans la réponse précédemment liée, l'application Twelve-Factor donne de bons conseils sur le sujet). Cela dépend de votre langue de plusieurs manières. L’un des plus faciles (en général) consiste simplement à définir des variables d’environnement. Ensuite, il vous suffit de modifier les variables en fonction de l’emplacement où vous vous trouvez - qu’il s’agisse d’une boîte de développement locale, d’un groupe de production ou de la production. Une autre option est de stocker les valeurs dans un .inifichier ou JSON. Une autre alternative consisterait à stocker vos valeurs de configuration en tant que code réel. En fonction de la langue ou de l'environnement que vous utilisez, cela peut être une bonne idée.

Mais le but ultime est de vous permettre de prendre une base de code, de la déposer sur n’importe quelle machine disposant de l’architecture / connectivité prise en charge, et de pouvoir l’exécuter sans modifier le code de quelque manière que ce soit.


1

Que faire si je veux exécuter le backend sur ma propre machine mais pas sur le port 55793, par exemple si j'exécutais plusieurs versions en même temps pour les comparer? Que faire si je veux exécuter le backend de l'application sur une machine, mais y accéder depuis une autre? Et si je veux ajouter un quatrième environnement? Comme d'autres l'ont fait remarquer, il suffit de recompiler pour changer la configuration de base.

L’approche que vous avez décrite a peut-être fonctionné jusqu’à présent pour votre équipe, mais elle est inutilement restrictive. Un système de configuration qui permet de définir des paramètres tels que ce chemin d'accès de manière arbitraire dans un fichier de configuration central est beaucoup plus flexible qu'un système qui ne fournit que des options fixes, et quel avantage en retirez-vous avec l'approche switch statement? Aucun!


0

C'est une mauvaise pratique .

Un principe de base de la conception logicielle: Ne codez pas les valeurs de configuration dans vos programmes. Cela est particulièrement vrai pour tout ce qui a une chance raisonnable de changer dans le futur.

Le code de programme que vous développez doit être le même que celui utilisé dans n'importe quel environnement, tel que les tests d'assurance qualité, les UAT et la production. Si quelqu'un doit modifier la configuration ultérieurement, parce que l'environnement a été modifié, ou s'il doit l'utiliser dans un nouvel environnement, c'est bien. Mais ils ne devraient jamais avoir à toucher votre code de programme pour le faire. Et vous ne devriez pas avoir différentes versions de code pour chaque environnement. Si votre programme a changé depuis qu'il a été testé, vous n'avez pas testé cette version. Demandez à n'importe quel ingénieur logiciel, à tout professionnel de l'assurance de la qualité des logiciels, à tout professionnel de la gestion de projet informatique, à tout auditeur informatique.

Quelqu'un pourrait déplacer les tests sur un autre serveur. Quelqu'un peut également décider de créer un environnement de formation des utilisateurs ou un environnement de démonstration des ventes. Ils ne devraient pas avoir à consulter un programmeur pour la configuration administrative.

Les logiciels doivent être suffisamment souples et robustes pour gérer des situations imprévues, dans des limites raisonnables.

De plus, les logiciels ne doivent pas être écrits simplement, mais cela vous semble plus facile pour le moment. Le coût du développement logiciel est faible comparé au coût de la maintenance du logiciel au cours de sa durée de vie. Et disons dans un an, vous n'êtes peut-être pas la personne qui travaille sur ce code. Vous devriez penser à ce que vous laissez au prochain pauvre imbécile qui doit ramasser tous les dégâts que vous pourriez avoir laissés derrière vous, peut-être des années après que vous soyez passé à des pâturages plus verts. Ou vous pouvez être celui qui reprend le code des années plus tard, ne croyant pas ce que vous avez fait à l'époque.

Codez les choses correctement, du mieux que vous pouvez. C'est moins susceptible de devenir un problème plus tard.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.