Mauvaise pratique - changer le boîtier pour définir l'environnement
Au cours des trois dernières années où j'ai travaillé en tant que développeur, j'ai vu de nombreux exemples où les gens utilisent une instruction switch pour définir le chemin (à 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/";
}
})();
Il a été discuté s'il s'agit d'une bonne ou d'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 mettre en œuvre cela.
quelqu'un peut-il expliquer les avantages et les inconvénients de la pratique ci-dessus?
Le 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 indiquer 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 dynamiquement, elles sont toujours codées en dur. Cela signifie que vous ne pouvez pas modifier ces ressources sans recompiler/redéployer votre application. Avec un fichier de configuration externe, vous n'auriez qu'à modifier ce fichier et redémarrer/recharger votre application.
Que ce soit ou non un problème dépend de ce que vous en faites. Dans un framework Javascript qui est automatiquement redistribué avec chaque demande de toute façon, ce n'est pas un problème du tout - la valeur modifiée se propagera à chaque utilisateur la prochaine fois qu'il utilisera l'application. Avec un déploiement sur site dans une langue compilée dans un endroit inaccessible, c'est en effet un très gros problème. La réinstallation de l'application peut prendre du temps, coûter cher ou être effectuée la 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 plus au premier exemple ou plus au deuxième exemple.
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 changer de serveur de développement? Ou vous devez basculer vers un autre emplacement? Vous ne pouvez pas car 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 à douze facteurs ( http://12factor.net/config ), mais c'est une bonne pratique pour toute application. Vous pouvez trouver que les variables d'environnement ne sont pas appropriées à votre situation, auquel cas je vous suggère de regarder le stockage de cette configuration dans une base de données de fichier de configuration à côté (mais pas vérifié avec) du code.
D'une part, (comme d'autres l'ont mentionné), c'est une mauvaise idée car vous liez des détails d'implémentation dans votre code. Cela rend difficile de changer les choses.
Comme mentionné dans cette réponse , si vous voulez ajouter un nouvel environnement maintenant, vous devez mettre à jour votre code partout , au lieu de il suffit d'ajouter votre programme à un nouvel environnement.
Il y a une autre faille sérieuse à faire cela dans votre code Javascript: vous exposez les éléments internes de votre entreprise à des attaquants potentiels. Bien sûr, vous pouvez être derrière un pare-feu, mais vous pouvez toujours avoir un employé mécontent ou quelqu'un qui laisse entrer un virus.
Les mauvaises nouvelles portent.
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 a d'excellents conseils sur le sujet) . Il existe plusieurs façons de procéder en fonction de votre langue. L'une des plus simples (généralement) consiste à définir simplement les variables d'environnement. Ensuite, vous modifiez simplement les variables en fonction de l'endroit où vous exécutez - que ce soit une boîte de développement locale, qa ou production. Une autre option consiste à stocker les valeurs dans un .ini fichier ou JSON. Une autre alternative serait de stocker vos valeurs de configuration sous forme de code réel. Selon la langue ou l'environnement que vous utilisez, cela peut ou non ê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 qui a l'architecture/connectivité prise en charge, et de pouvoir l'exécuter sans modifier le code en aucune façon.
Que faire si je souhaite exécuter le backend sur ma propre machine mais pas sur le port 55793, par exemple si j'exécute plusieurs versions en même temps pour les comparer? Que faire si je veux exécuter le backend d'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 souligné, vous devez recompiler juste pour changer la configuration de base.
L'approche que vous avez décrite peut avoir fonctionné jusqu'à présent pour votre équipe, mais elle est inutilement restrictive. Un système de configuration qui permet de définir arbitrairement des paramètres comme ce chemin dans un fichier de configuration central est beaucoup plus flexible qu'un système qui ne fournit que des options fixes, et quel avantage retirez-vous de l'approche de l'instruction switch? Aucun!
C'est une MAUVAISE PRATIQUE.
Un principe de base de la conception de logiciels: ne codez pas en dur les valeurs de configuration dans vos programmes. Cela est particulièrement vrai pour tout ce qui a une chance raisonnable de changer à l'avenir.
Le code de programme que vous développez doit être le même code que celui utilisé dans n'importe quel environnement tel que les tests d'assurance qualité, l'UAT et la production. Si quelqu'un a besoin de changer la configuration plus tard parce que l'environnement a changé ou doit l'utiliser dans un nouvel environnement, très 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 qualité des logiciels, à n'importe quel I.T. professionnel en gestion de projet, tout I.T. Auditeur.
Quelqu'un pourrait déplacer les tests vers un autre serveur. Quelqu'un peut décider de vouloir également un environnement de formation des utilisateurs ou un environnement pour les démonstrations de vente. Ils ne devraient pas avoir à consulter un programmeur pour la configuration administrative.
Le logiciel doit être suffisamment flexible et robuste pour gérer des situations inattendues, dans des limites raisonnables.
De plus, le logiciel ne doit pas être écrit simplement mais vous semble le plus simple pour le moment. Le coût du développement logiciel est faible par rapport au coût de la maintenance logicielle sur sa durée de vie. Et disons que dans un an, vous pourriez ne pas être la personne qui travaille sur ce code. Vous devriez penser à ce que vous quittez pour le prochain pauvre imbécile qui doit ramasser le gâchis que vous pourriez avoir laissé, peut-être des années après que vous ayez poursuivi vos pâturages plus verts. Ou vous pouvez être celui qui récupère 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 le pouvez. Il est moins susceptible de devenir un problème plus tard.