Je « suis un codeur autodidacte et novice, donc je mexcuse si je ne sais pas le jargon du programmeur.
Je travaille sur un projet dans lequel je fournis des données, qui seront continuellement mises à jour, à des développeurs qui créeront essentiellement un outil pour générer des rapports à partir de requêtes sur les données.
Il semble que toutes les personnes impliquées pensent quils ont besoin de coder en dur les valeurs de données (pas le schéma, mais les domaines / valeurs eux-mêmes) dans le programme de génération de rapports.
Par exemple, supposons que nous rendions compte du personnel; le rapport serait divisé en catégories, avec un en-tête pour chaque département, puis sous chaque en-tête de département se trouveront des sous-titres des titres de poste, puis sous chaque sous-titre se trouvera une liste demployés. Les développeurs souhaitent coder en dur les départements et les intitulés de poste. dautre part, je pense quils pourraient / voudraient interroger ces choses au moment de lexécution, trier les enregistrements par eux et générer des en-têtes de rapport dynamiquement en fonction de la valeur es sont là.
Étant donné que la liste des valeurs potentielles changera au fil du temps (par exemple, les départements seront créés / renommés, de nouveaux titres de poste seront ajoutés), le code devra être continuellement mis à jour. Il me semble que nous pourrions sauter les étapes de maintenance du code et organiser dynamiquement les rapports.
Comme je ne suis pas développeur, je me demande ce qui me manque. Quels avantages pourrait-il y avoir à coder en dur des valeurs dans un outil comme celui-ci? Est-ce généralement ainsi que les programmes sont conçus?
Commentaires
- duplication possible de Suppression du code en dur valeurs et conception défensive par rapport à YAGNI
- Les rapports sont-ils des tableaux croisés, ce qui signifie que les valeurs dans les lignes doivent apparaître sous forme de colonnes?
- @Brendan – Si vous codez en dur les valeurs dans le rapport , vous ‘ devrez changer la liste à DEUX endroits (source de données et rapport) alors que si le rapport est dynamique, il vous suffit de le changer à un seul endroit (le rapport) .
- @Brendan pourquoi vous retrouveriez-vous avec trois emplacements? Peut-être que ma compréhension est incorrecte, mais je ‘ m envisage une requête SQL pour récupérer des données à partir dune base de données, lapplication agrégera / regroupera les valeurs renvoyées par, par exemple, le département. Si vous ‘ êtes prêt à supporter la surcharge de plusieurs requêtes de base de données, vous pouvez sélectionner des départements / titres de rôle distincts si vous le souhaitez vraiment. À aucun moment, les données nexistent à plus dun endroit – le rapport est géré par les données.
- @Brendan Je ne suis pas non plus daccord avec votre définition du fait quil se trouve à un seul endroit – la façon dont vous le décrivez ‘ à plusieurs emplacements, dispersés dans le code source.
Réponse
Wikipédia:
Difficile le codage (également codé en dur ou en dur) fait référence à la pratique de développement de logiciel consistant à intégrer ce qui peut, peut-être seulement rétrospectivement, être considéré comme une entrée ou des données de configuration directement dans le code source dun programme ou dun autre objet exécutable, ou au données, au lieu dobtenir ces données de sources externes ou de générer des données ou de les mettre en forme dans le programme lui-même avec lentrée donnée.
Le codage en dur est considéré comme un antipattern .
Considéré comme un n anti-pattern, le codage en dur nécessite que le code source du programme soit modifié à chaque fois que les données dentrée ou le format souhaité changent, alors quil pourrait être plus pratique pour lutilisateur final de modifier les détails par certains moyens en dehors du programme. p>
Parfois, vous ne pouvez pas léviter mais cela devrait être temporaire.
Le codage en dur est souvent requis. Les programmeurs peuvent ne pas disposer dune solution dinterface utilisateur dynamique pour lutilisateur final, mais doivent tout de même fournir la fonctionnalité ou libérer le programme. Ceci est généralement temporaire mais résout, à court terme, la pression pour livrer le code. Plus tard, le codage logiciel est effectué pour permettre à un utilisateur de transmettre des paramètres qui permettent à lutilisateur final de modifier les résultats ou le résultat.
- Hardcoding de messages rend difficile linternationalisation dun programme.
- Les chemins de codage en dur rendent difficile ladaptation à un autre emplacement.
Le seul avantage du codage en dur semble être la livraison rapide du code.
Commentaires
- OK , mais le » seul avantage » est souvent extrêmement important. Les décisions de conception en matière de programmation concernent souvent le compromis entre la vérification future et la livraison rapide maintenant, et en tant que tel, le codage en dur peut être un choix parfaitement acceptable. Parfois, le codage en dur pas est un mauvais choix de conception.
- -1 Je ne ‘ Je pense que cest une réponse utile. Il dit essentiellement que ‘ incorporer des valeurs dans le code source de manière inappropriée ‘ est inapproprié. Je pense que lOP veut des conseils sur le moment où les choses peuvent appartenir au code source et donc ne pas correspondre à votre définition de Wikipédia.
- Le codage en dur devrait être une partie vitale de votre processus et le considérer comme un anti-modèle est obsolète dans le lère des micro-services, le didacticiel Angular Tour of Heroes étant un exemple très médiatisé dune énorme société de logiciels encourageant directement ou même mandatant comme étape intermédiaire. De plus, lorsque vous passez aux données dynamiques, vous devez toujours conserver certaines données codées en dur comme solution de secours, peut-être contrôlée par une variable denvironnement ou même par une bascule booléenne sur le code lui-même afin que les bogues et les problèmes de sécurité puissent être correctement isolés. ligne.
Réponse
Vraiment? Aucun cas dutilisation valide possible?
Bien que je convienne que le codage en dur est généralement un anti-pattern ou au moins une très mauvaise odeur de code , il y a beaucoup de cas où cela a du sens. En voici quelques-uns.
-
Simplicité / YAGNI .
-
Constantes réelles qui ne changent jamais en réalité.
cest-à-dire que la constante représente un naturel ou entreprise constante, ou une approximation de un. (par exemple 0, PI, …)
-
Contraintes environnementales matérielles ou logicielles
Dans les logiciels embarqués, les contraintes de mémoire et dallocation viennent à lesprit.
-
Logiciel sécurisé
Ces valeurs ne sont pas disponibles et / ou faciles à décoder ou à rétroconcevoir, par exemple jetons et sels cryptographiques. (Notez que les garder codés en dur présente également des inconvénients évidents …)
-
Code généré
Votre préprocesseur ou générateur est configurable, mais crache du code avec des valeurs codées en dur. Ce nest pas inhabituel pour le code qui repose sur des moteurs de règles ou si vous avez une architecture basée sur un modèle.
-
Code haute performance
Dune certaine manière, ce code est » généré » , bien que plus spécialisé encore. par exemple. une table de recherche / calcul prédéterminée avec des changements improbables. Ce nest pas du tout inhabituel dans la programmation graphique par exemple.
-
Configuration et solutions de secours
Tant dans votre code réel que dans vos fichiers de configuration, vous êtes susceptible davoir des valeurs de configuration, et des solutions de secours dans plusieurs cas (lorsque la configuration nest pas disponible, lorsquun composant ne répond pas comme attendu, etc …). Néanmoins, il est généralement préférable de le garder en dehors de votre code et de le rechercher, mais il peut arriver que vous souhaitiez absolument avoir une valeur / réaction spécifique à une action / un problème / une situation spécifique.
-
Et probablement quelques autres …
Encore un Anti-Pattern ? Il en va de même pour Over-Engineering ! Il s’agit de l’espérance de vie de votre logiciel !!
Ce n’est pas ce que je dis il y a toutes de bonnes raisons, et en général je rechigne aux valeurs codées en dur. Mais certains peuvent facilement obtenir un laissez-passer pour des raisons valables.
Et ne supervisez pas la première concernant la simplicité / YAGNI soit en pensant que cest trivial: il ny a probablement aucune raison dimplémenter un analyseur fou et un vérificateur de valeur pour un script simple qui fait un travail pour un cas dutilisation étroit très bien.
Il est difficile de trouver le bal ance. Parfois, vous ne prévoyez pas quun logiciel se développera et durera plus longtemps que le simple script dans lequel il a commencé. Souvent, cest linverse: nous sur-ingénierie, et un projet est mis sur les tablettes plus vite que vous ne le pouvez lisez le programmeur pragmatique. Vous avez perdu du temps et des efforts sur des choses que les premiers prototypes n’avaient pas besoin.
C’est ce qui est méchant avec les Anti-Patterns: ils « sont présents dans les deux extrêmes du spectre, et leur apparence dépend du sensibilité de la personne qui examine votre code.
Personnellement, jaurais tendance à toujours suivre la voie générique, dès que je vois que quelque chose pourrait changer ou si je « Jai dû le faire plus dune fois. Mais une approche plus précise consisterait à évaluer soigneusement le coût du codage en dur par rapport à la génération ou à la génération de votre code pour cette situation spécifique.Cest la même chose que de déterminer si une tâche vaut la peine dêtre automatisée plutôt que de la faire manuellement. Tenez simplement compte du temps et du coût.
Commentaires
- Ce ‘ est drôle, car je lai piloté moi-même, et il était beaucoup plus facile, plus rapide et plus propre pour moi de gérer les valeurs de manière dynamique. Je lai fait en Python, alors que je pense que le produit final sera codé en Java – si cela fait une différence. Cela me semblait sur-conçu lorsque je codais en dur les valeurs, car chaque colonne entrante devait être suivie à plusieurs endroits.
- @Tom: Vous ‘ dites quil était plus facile et plus rapide dimplémenter (ou même de réutiliser) une bibliothèque de recherche de configuration que dutiliser une valeur codée en dur? pour vous. De plus, je ne ‘ voir comment votre dernière phrase correspond à la définition de la sur-ingénierie. anguille évidemment en désordre, et évidemment si elle ‘ est codée en dur et dupliquée ‘ est encore pire (ce qui n’était pas le but de votre question question, jai probablement mal compris, mais il ma semblé que vous vouliez dire que la valeur nétait pas codée en dur à chaque fois, mais en un seul point du programme).
- Quoi quil en soit, je ‘ m indiquant simplement les cas où ‘ d être valide. Je ‘ m faisant également remarquer que cela ‘ serait controversé dans ma dernière phrase. Vous pouvez ‘ t plaire à tout le monde et les équipes ont des personnes avec des niveaux de compétence différents.
- @Tom, don ‘ t vendez-vous trop court. Vous ‘ êtes définitivement sur quelque chose. Il semble plus facile et moins long d’écrire un algorithme rapide pour organiser les données en examinant les champs Département et Titre du poste par opposition au codage en dur
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']. Il serait également beaucoup plus difficile de maintenir le tableau codé en dur dans le cas où un nouveau département ou un nouveau titre serait introduit. - Vous pouvez avoir des choses plus complexes qui sont toujours sensibles au codage en dur. Celui qui me vient à lesprit que jai écrit il y a quelques années était toutes les permutations possibles dun ensemble de valeurs. Javais besoin de trouver une direction aléatoire valide, choisir une permutation aléatoire puis prendre le premier résultat valide était de loin la solution la plus efficace et comme cétait dans une boucle O (N ^ 3), lefficacité importait.
Réponse
Il est parfois possible de coder des valeurs en dur. Par exemple, il y a des nombres comme 0, ou un ou diverses valeurs n ^ 2-1 pour les masques de bits qui doivent être certaines valeurs à des fins algorithmiques. Autoriser de telles valeurs au configurable na aucune valeur et ouvre uniquement la possibilité de problèmes. En dautres termes, si la modification dune valeur ne ferait que casser des choses, il devrait probablement être codé en dur.
Dans lexemple que vous avez donné, je ne vois pas où le codage en dur serait utile. Tout ce que vous mentionnez serait / devrait déjà être dans la base de données, y compris les en-têtes. Même les éléments qui déterminent la présentation (comme lordre de tri) peuvent être ajoutés sils ny figurent pas.
Commentaires
- Merci. Lordre de tri était la seule préoccupation que javais. Cependant, dans notre cas, cela na ‘ t important, et je nai ‘ t considérer que cela pourrait être ajouté comme une autre table dans la base de données.
- Je dois noter que la gestion de tout cela dans la base de données est une option. Vous pouvez également utiliser des fichiers de configuration ou dautres solutions, mais le codage en dur semble être un mauvais choix. La base de données Cette option est souvent utilisée car il est ‘ facile de créer une interface permettant aux utilisateurs de gérer les options. Il existe également des outils comme this qui sont spécifiquement conçus à cet effet.
Réponse
Implémentation dune solution robuste qui permet aux valeurs qui auraient autrement été codées en dur dêtre à la place configurables par les demandes des utilisateurs finaux validation robuste de ces valeurs. Ont-ils mis une chaîne vide? Ont-ils mis quelque chose de non numérique là où cela aurait dû être un nombre? Font-ils une injection SQL? Etc.
Le codage en dur évite beaucoup de ces risques.
Ce qui ne veut pas dire que le codage en dur est toujours, voire souvent, une bonne idée. Cest juste lun des facteurs à prendre en compte.