Permettez-moi de vous poser une contre-question tout à fait sérieuse: quelle est, selon vous, la différence entre "données" et "code"?
Quand j'entends le mot «données», je pense «état». Les données sont, par définition, la chose que l'application elle-même est conçue pour gérer, et donc la chose même que l'application ne peut jamais connaître au moment de la compilation. Il n'est pas possible de coder en dur les données, car dès que vous les codez en dur, cela devient un comportement - pas des données.
Le type de données varie selon l'application; un système de facturation commercial peut stocker des informations sur les clients et les commandes dans une base de données SQL, et un programme de graphiques vectoriels peut stocker des données de géométrie et des métadonnées dans un fichier binaire. Dans ces deux cas et tout le reste, il existe une séparation claire et incassable entre le code et les données. Les données appartiennent à l' utilisateur , pas au programmeur, donc elles ne peuvent jamais être codées en dur.
Ce dont vous semblez parler, c'est d'utiliser la description la plus précise techniquement disponible de mon vocabulaire actuel: des informations régissant le comportement du programme qui ne sont pas écrites dans le langage de programmation principal utilisé pour développer la majorité de l'application.
Même cette définition, qui est considérablement moins ambiguë que le seul mot «données», pose quelques problèmes. Par exemple, que se passe-t-il si des parties importantes du programme sont chacune écrites dans des langues différentes? J'ai personnellement travaillé sur plusieurs projets qui sont environ 50% C # et 50% JavaScript. Le code JavaScript est-il "données"? La plupart des gens diraient non. Qu'en est-il du HTML, est-ce que ces "données"? La plupart des gens diraient toujours non.
Et CSS? S'agit-il de données ou de code? Si nous considérons le code comme quelque chose qui contrôle le comportement du programme, alors le CSS n'est pas vraiment du code, car il affecte seulement (enfin, principalement) l'apparence, pas le comportement. Mais ce ne sont pas vraiment des données non plus; l'utilisateur ne le possède pas, l'application ne le possède même pas vraiment. C'est l'équivalent du code pour un concepteur d'interface utilisateur. C'est comme du code, mais pas tout à fait du code.
Je pourrais appeler CSS une sorte de configuration, mais une définition plus pratique est qu'il s'agit simplement de code dans un langage spécifique au domaine . C'est ce que représentent souvent votre XML, YAML et d'autres "fichiers formatés". Et la raison pour laquelle nous utilisons un langage spécifique au domaine est que, d'une manière générale, il est simultanément plus concis et plus expressif dans son domaine particulier que le codage des mêmes informations dans un langage de programmation à usage général comme C ou C # ou Java.
Reconnaissez-vous le format suivant?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
Je suis sûr que la plupart des gens le font; c'est JSON . Et voici la chose intéressante à propos de JSON: en JavaScript, c'est clairement du code, et dans toutes les autres langues, ce sont des données clairement formatées. Presque tous les langages de programmation traditionnels ont au moins une bibliothèque pour "analyser" JSON.
Si nous utilisons exactement la même syntaxe à l'intérieur d'une fonction dans un fichier JavaScript, cela ne peut pas être autre chose que du code. Et pourtant, si nous prenons ce JSON, le poussons dans un .jsonfichier et l'analysons dans une application Java, tout à coup ce sont des «données». Est-ce vraiment logique?
Je soutiens que le "data-ness" ou "configuration-ness" ou "code-ness" est inhérent à ce qui est décrit, pas comment il est décrit.
Si votre programme a besoin d'un dictionnaire de 1 million de mots pour, par exemple, générer une phrase de passe aléatoire, voulez-vous le coder comme ceci:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
Ou voudriez-vous simplement insérer tous ces mots dans un fichier texte délimité par des lignes et dire à votre programme de le lire? Cela n'a pas vraiment d'importance si la liste de mots ne change jamais, ce n'est pas une question de savoir si vous codez en dur ou codez en douceur (que beaucoup considèrent à juste titre comme un anti-modèle lorsqu'il est appliqué de manière inappropriée), c'est simplement une question de quel format est le plus efficace et permet de décrire plus facilement le "truc", quel que soit le "truc". Ce n'est pas pertinent que vous l'appeliez code ou données; ce sont les informations dont votre programme a besoin pour fonctionner, et un format de fichier plat est le moyen le plus pratique pour le gérer et le maintenir.
En supposant que vous suiviez les bonnes pratiques, tout cela passe de toute façon dans le contrôle de code source, donc vous pourriez aussi bien l'appeler du code, juste du code dans un format différent et peut-être très minimaliste. Ou vous pouvez l'appeler configuration, mais la seule chose qui distingue vraiment le code de la configuration est de savoir si vous le documentez et dites aux utilisateurs finaux comment le modifier. Vous pourriez peut-être inventer un faux argument au sujet de l'interprétation de la configuration au moment du démarrage ou de l'exécution et non au moment de la compilation, mais alors vous commenceriez à décrire plusieurs langages à typage dynamique et presque certainement n'importe quoi avec un moteur de script intégré à l'intérieur (par exemple la plupart des jeux). Le code et la configuration sont ce que vous décidez de les étiqueter, rien de plus, rien de moins.
Désormais, il existe un danger d' externalisation d' informations qui ne sont pas réellement sûres à modifier (voir le lien "codage logiciel" ci-dessus). Si vous externalisez votre groupe de voyelles dans un fichier de configuration et le documentez en tant que fichier de configuration à vos utilisateurs finaux, vous leur donnez un moyen presque infaillible de casser instantanément votre application, par exemple en mettant "q" comme voyelle. Mais ce n'est pas un problème fondamental avec la "séparation du code et des données", c'est tout simplement un mauvais sens du design.
Ce que je dis aux développeurs juniors, c'est qu'ils devraient toujours externaliser les paramètres qu'ils s'attendent à changer par environnement. Cela inclut des éléments tels que les chaînes de connexion, les noms d'utilisateur, les clés d'API, les chemins de répertoire, etc. Ils peuvent être les mêmes sur votre boîte de développement et en production, mais probablement pas, et les administrateurs système décideront à quoi ils veulent ressembler en production, pas les développeurs. Vous avez donc besoin d'un moyen d'appliquer un groupe de paramètres sur certaines machines et d'autres paramètres sur d'autres machines - ergo, fichiers de configuration externes (ou paramètres dans une base de données, etc.)
Mais j'insiste sur le fait que le simple fait de mettre des "données" dans un "fichier" n'est pas la même chose que de l'externaliser en tant que configuration. Mettre un dictionnaire de mots dans un fichier texte ne signifie pas que vous voulez que les utilisateurs (ou l'informatique) le changent, c'est juste un moyen de permettre aux développeurs de comprendre plus facilement ce qui se passe et, si nécessaire, de faire changements occasionnels. De même, le fait de placer les mêmes informations dans une table de base de données ne compte pas nécessairement comme une externalisation du comportement, si la table est en lecture seule et / ou les administrateurs de base de données sont invités à ne jamais se tromper avec. La configuration implique que les données sont modifiables, mais en réalité cela est déterminé par le processus et les responsabilités plutôt que par le choix du format.
Donc, pour résumer:
"Code" n'est pas un terme défini de manière rigide. Si vous développez votre définition pour inclure des langages spécifiques au domaine et tout ce qui affecte le comportement, une grande partie de cette friction apparente disparaîtra tout simplement et tout cela aura du sens. Vous pouvez avoir un "code" DSL non compilé dans un fichier plat.
Les «données» impliquent des informations qui appartiennent à l'utilisateur ou à au moins une personne autre que les développeurs et qui ne sont généralement pas disponibles au moment de la conception. Il ne pouvait pas être codé en dur, même si vous le vouliez. À l'exception possible du code auto-modifiable , la séparation entre le code et les données est une question de définition et non de préférence personnelle.
Le "codage logiciel" peut être une pratique terrible lorsqu'il est sur-appliqué, mais toutes les instances d'externalisation ne constituent pas nécessairement un codage logiciel, et de nombreuses instances de stockage d'informations dans des "fichiers plats" ne sont pas nécessairement une tentative d'externalisation de bonne foi.
La configuration est un type spécial de codage logiciel qui est nécessaire en raison de la connaissance que l'application peut avoir besoin de s'exécuter dans différents environnements. Le déploiement d'un fichier de configuration séparé avec l'application est beaucoup moins de travail (et beaucoup moins dangereux) que le déploiement d'une version différente du code dans chaque environnement. Ainsi , certains types de codage doux sont réellement utiles.