Y a-t-il des avantages à coder en dur des valeurs de données dans un programme?

Je suis un codeur autodidacte novice, donc je m'excuse si je ne cloue pas le jargon du programmeur.

Je travaille sur un projet dans lequel je fournis des données, qui seront continuellement mises à jour, aux 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 qu'elles doivent coder en dur les valeurs des 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 il y aurait des sous-titres de postes, puis sous chaque sous-titre une liste d'employés. Les développeurs veulent coder en dur les départements et les titres d'emploi. D'un autre côté, je penserais qu'ils pourraient / demanderaient ces choses au moment de l'exécution, trieraient les enregistrements par eux et généreraient des en-têtes de rapport dynamiquement en fonction des valeurs qui s'y trouvent.

É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 d'emploi seront ajoutés), le code devra être continuellement mis à jour. Il me semble que nous pourrions ignorer 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 peut-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?

Wikipédia:

Le codage en dur (également en codage en dur ou en codage en dur) fait référence à la pratique de développement de logiciels consistant à incorporer 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 d'un programme ou d'un autre objet exécutable, ou un formatage fixe de les données, au lieu d'obtenir ces données à partir de sources externes ou de générer des données ou un formatage dans le programme lui-même avec l'entrée donnée.

Le codage en dur est considéré comme un contre-modèle.

Considéré comme anti-modèle, le codage en dur nécessite que le code source du programme soit modifié à chaque fois que les données d'entrée ou le format souhaité changent, quand il pourrait être plus pratique pour l'utilisateur final de modifier les détails par un moyen extérieur au programme.

Parfois, vous ne pouvez pas l'éviter mais cela devrait être temporaire.

Un codage dur est souvent requis. Les programmeurs peuvent ne pas avoir de solution d'interface utilisateur dynamique pour l'utilisateur final, mais doivent toujours fournir la fonctionnalité ou libérer le programme. Ceci est généralement temporaire, mais résout, dans un sens à court terme, la pression pour livrer le code. Plus tard, un codage logiciel est effectué pour permettre à un utilisateur de transmettre des paramètres qui donnent à l'utilisateur final un moyen de modifier les résultats ou les résultats.

• Le codage en dur des messages rend difficile l'internationalisation d'un programme.
• Les chemins de codage en dur rendent difficile l'adaptation à un autre emplacement.

Le seul avantage du codage en dur semble être la livraison rapide de code.

Vraiment? Aucun cas d'utilisation valide possible?

Bien que je convienne que le codage en dur est généralement un anti-modèle ou au moins une très mauvaise odeur de code , il existe de nombreux cas où cela a du sens:

• simplicité ( YAGNI ),
• l'entrée est en fait constante et ne changera jamais (c'est-à-dire qu'elle représente une constante naturelle ou commerciale ou une approximation de une. Par exemple 0, PI, ...),
• logiciels embarqués (les contraintes de mémoire et d'allocation viennent à l'esprit),
• un logiciel sécurisé (ces valeurs ne sont pas disponibles et / ou faciles à décoder ou à rétroconcevoir, par exemple des jetons cryptographiques et des sels),
• code généré (votre préprocesseur ou générateur est configurable, mais crache du code avec des valeurs codées en dur),
• et probablement un peu plus.

Toujours un anti-modèle ? La suringénierie aussi ! Il s'agit de l'espérance de vie de votre logiciel !!

Non pas que je dis qu'il y a toutes de bonnes raisons, et généralement je rechigne à des valeurs codées en dur. Mais certains peuvent facilement obtenir un laissez-passer pour des raisons valables.

Et ne supervisez pas le premier concernant la simplicité / YAGNI en pensant que c'est trivial: il n'y a probablement aucune raison d'implémenter un analyseur et un vérificateur de valeur fou pour un script simple qui fait très bien un travail pour un cas d'utilisation étroit.

Il est difficile de trouver l'équilibre. Parfois, vous ne prévoyez pas qu'un logiciel grandira et durera plus longtemps que le simple script au départ. Souvent, cependant, c'est l'inverse: nous sur-concevons les choses, et un projet est abandonné plus rapidement que vous ne pouvez le lire dans le programmeur pragmatique. Vous avez perdu du temps et des efforts sur des choses qu'un premier prototype n'avait pas besoin.

Voilà les choses méchantes avec les anti-modèles: ils sont présents dans les deux extrêmes du spectre, et leur apparence dépend de la sensibilité de la personne qui examine votre code.

Parfois, il est OK de coder en dur les valeurs. Par exemple, il existe des nombres comme 0, ou une ou plusieurs valeurs n ^ 2-1 pour les masques de bit qui doivent être certaines valeurs à des fins algorithmiques. Autoriser de telles valeurs au configurable n'a aucune valeur et ouvre seulement la possibilité de problèmes. En d'autres termes, si la modification d'une valeur ne faisait que casser des choses, elle devrait probablement être codée en dur.

Dans l'exemple que vous avez donné, je ne vois pas où le codage en dur serait utile. Tout ce que vous mentionnez devrait / devrait déjà être dans la base de données, y compris les titres. Même les éléments qui déterminent la présentation (comme l'ordre de tri) peuvent être ajoutés s'ils ne s'y trouvent pas.

La mise en œuvre d'une solution robuste qui permet à des valeurs qui auraient autrement été codées en dur d'être configurées à la place par les utilisateurs finaux nécessite une validation robuste de ces valeurs. Ont-ils mis une chaîne vide? Ont-ils mis quelque chose de non numérique où il aurait dû être un nombre? Font-ils l'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, ou même souvent, une bonne idée. Ce n'est là qu'un des facteurs à prendre en compte.