Voici une citation de Linus Torvalds pour 2006 :

Je suis un grand partisan du développement de code autour des données, et non l'inverse, et je pense que c'est l'une des raisons pour lesquelles git a été un succès ... En fait, je soutiens que la différence entre un mauvais programmeur et un bon est de savoir s'il pense plus important votre code ou vos structures de données. Les mauvais programmeurs s'inquiètent du code. Les bons programmeurs se soucient des structures de données et de leurs relations.

Ce qui est très similaire à la "règle de soumission" d'Eric Raymond de 2003 :

Transformez les connaissances en données afin que la logique du programme devienne stupide et fiable.

Voici juste un résumé d'idées comme la pensée de Rob Pike en 1989 :

Les données dominent. Si vous choisissez les bonnes structures de données et organisez tout bien, les algorithmes seront presque toujours évidents. Les structures de données, et non les algorithmes, jouent un rôle central dans la programmation.

Il cite Fred Brooks de 1975 :

La présentation est l'essence de la programmation

Derrière la maîtrise, il y a l'ingéniosité qui fait
programmes économiques et rapides. C'est presque toujours le résultat.
percée stratégique, pas de compétence tactique. Parfois si stratégique
une percée est un algorithme, comme une transformée de Fourier rapide,
proposé par Cooley et Tukey, ou en remplaçant n ² les comparaisons par n log n lors du tri.

Le plus souvent, une percée stratégique résulte de la présentation
données ou tableaux. Le cœur du programme est ici. Montrez-moi les organigrammes sans montrer les tableaux, et je resterai égaré. Montrez-moi votre
les tableaux et les organigrammes ne sont probablement pas nécessaires: ils seront évidents.

Ainsi, depuis près d'un demi-siècle, les gens intelligents ont dit et répété: se concentrer d'abord sur les données. Mais parfois, il semble que ce soit le conseil le plus intelligent que tout le monde oublie.

Je vais donner de vrais exemples.

Système hautement évolutif qui a échoué

Ce système a été créé à l'origine dans l'espoir d'une évolutivité incroyable avec une charge importante sur le processeur. Rien de synchrone. Partout les rappels, les files d'attente et les pools de travail.

Mais il y avait deux problèmes. La première était que la «charge du processeur» n'était pas si intense - une tâche a pris un maximum de quelques millisecondes. La plupart de l'architecture a donc fait plus de mal que de bien. Le deuxième problème était que le "système distribué hautement évolutif" ne fonctionnait en fait que sur une seule machine. Pourquoi? Parce que toutes les communications entre les composants asynchrones ont été effectuées à l'aide de fichiers dans le système de fichiers local, qui est maintenant devenu un goulot d'étranglement pour toute mise à l'échelle. La conception d'origine n'était pas du tout liée aux données, à l'exception de la protection des fichiers locaux au nom de la «simplicité». La majeure partie du projet a été consacrée à toute cette architecture supplémentaire, qui était «évidemment» nécessaire pour faire face à la «lourde charge» sur le CPU.

Une architecture orientée services toujours orientée données

Ce système a suivi la conception de microservices à partir d'applications à usage unique avec des API REST. L'un des éléments était une base de données dans laquelle les documents sont stockés (principalement les réponses aux formulaires standard et autres documents électroniques). Naturellement, elle a défini l'API pour l'enregistrement et la récupération des données, mais assez rapidement, il y avait un besoin de fonctionnalités de recherche plus complexes. Les développeurs ont estimé que l'ajout de cette fonction à un document API existant contredit les principes de conception de microservices. Étant donné que «recherche» est essentiellement différent de «get / put», l'architecture ne doit pas les combiner. En outre, ils envisageaient d'utiliser un outil tiers pour travailler avec l'index, de sorte que la création d'une nouvelle «recherche» de services était également logique pour cette raison.

En conséquence, une API de recherche et un index de recherche ont été créés, qui sont essentiellement devenus un doublon des données de la base de données principale. Ces données ont été mises à jour dynamiquement, donc tout composant qui a modifié les données du document via l'API de base de données principale doit également envoyer une demande de mise à jour de l'index via l'API de recherche. À l'aide de l'API REST, cela ne peut pas être fait sans condition de concurrence, de sorte que les deux jeux de données se désynchronisent de temps en temps.

Malgré ce que l'architecture avait promis, les deux API étaient étroitement liées par leurs dépendances de données. Plus tard, les développeurs ont reconnu que l'index de recherche devrait être combiné avec un service de document commun, ce qui a rendu le système beaucoup plus maintenable. Doing One fonctionne au niveau des données, mais pas au niveau des verbes.

Boue de boue incroyablement modulaire et configurable

Ce système était une sorte de pipeline de déploiement automatisé. L'équipe de développement d'origine voulait rendre un outil suffisamment flexible pour résoudre les problèmes de déploiement dans toute l'entreprise. Ils ont écrit un ensemble de composants de plug-in avec un système de fichiers de configuration qui a non seulement configuré les composants, mais a également agi comme un langage spécifique au domaine (DSL) pour programmer la façon dont les composants s'insèrent dans le pipeline.

Avance rapide jusqu'à quelques années, et l'outil est devenu "le programme même". Il y avait une longue liste d'erreurs connues que personne n'avait jamais corrigées. Personne ne voulait toucher au code de peur de casser quelque chose. Personne n'a utilisé la flexibilité du DSL. Tous les utilisateurs ont copié et collé la même configuration de travail garantie que tout le monde.

Qu'est-ce qui a mal tourné? Bien que le document de projet original ait souvent utilisé des mots tels que «modulaire», «déconnecté», «extensible» et «personnalisé», il n'a rien dit du tout sur les données. Ainsi, les dépendances de données entre les composants ont été traitées de manière non réglementée à l'aide d'un blob JSON commun à l'échelle mondiale. Au fil du temps, les composants ont émis de plus en plus d'hypothèses non documentées sur ce qui est inclus ou non dans le blob JSON. Bien sûr, DSL permettait de réorganiser les composants dans n'importe quel ordre, mais la plupart des configurations ne fonctionnaient pas.

Les leçons

J'ai choisi ces trois projets, car il est facile d'expliquer la thèse générale à l'aide de leur exemple, sans toucher aux autres. Une fois, j'ai essayé de créer un site Web et j'ai plutôt suspendu une sorte de base de données XML servile qui n'a même pas résolu mes problèmes de données. Il y avait un autre projet qui s'est transformé en un semblant cassé de la moitié des fonctionnalités de make , encore une fois parce que je ne pensais pas ce dont j'avais vraiment besoin. J'ai déjà écrit sur le temps passé à créer une hiérarchie sans fin de classes OOP qui auraient dû être encodées dans les données .

Mise à jour:

Apparemment, beaucoup pensent encore que j'essaie de me moquer de quelqu'un. Mes vrais collègues savent que je suis beaucoup plus intéressé à résoudre de vrais problèmes, et non à blâmer ceux qui ont généré ces problèmes, mais, d'accord, c'est ce que je pense des développeurs impliqués dans ces projets.

Honnêtement, la première situation s'est clairement produite parce que l'architecte système était plus intéressé à appliquer des travaux scientifiques qu'à résoudre un problème réel. Beaucoup d'entre nous peuvent être blâmés pour cela (moi aussi), mais cela agace vraiment nos collègues. Après tout, ils devront apporter leur soutien lorsque nous nous lasserons d'un jouet. Si vous vous reconnaissez, ne soyez pas offensé, veuillez simplement arrêter (même si je préférerais travailler avec un système distribué sur un nœud plutôt qu'avec n'importe quel système sur ma «base de données XML»).

Dans le deuxième exemple, il n'y a rien de personnel. Parfois, il semble que tout le monde dit à quel point il est merveilleux de partager des services, mais personne ne parle du meilleur moment pour ne pas le faire. Les gens apprennent tout le temps de leur propre expérience amère.

La troisième histoire est en fait arrivée à certaines des personnes les plus intelligentes avec lesquelles j'ai travaillé.

(Fin de mise à jour).

La question "Que dit-on des problèmes créés par les données?" Il s'avère être un test décisif très utile pour une bonne conception du système. Il est également très pratique pour identifier de faux «experts» avec leurs conseils. Les problèmes d'architecture de systèmes complexes et compliqués sont des problèmes de données, donc les faux experts aiment les ignorer. Ils vous montreront une architecture étonnamment belle, mais ils ne diront rien sur les données auxquelles il convient et (surtout) sur quelles données il ne convient pas.

Par exemple, un faux expert pourrait dire que vous devriez utiliser le système pub / sub car les systèmes pub / sub sont faiblement couplés et les composants faiblement couplés sont plus faciles à maintenir. Cela semble beau et donne de beaux diagrammes, mais c'est l'inverse de la pensée. Pub / sub ne fait pas vos composants lâchement couplés; pub / sub lui-même est faiblement couplé, ce qui peut ou non convenir à vos besoins de données.

D'un autre côté, une architecture orientée données bien conçue est d'une grande importance. Programmation fonctionnelle, maillage de service, RPC, modèles de conception, boucles d'événements, peu importe, chacun a ses propres mérites. Mais personnellement, j'ai vu que des systèmes de production beaucoup plus performants fonctionnaient sur des anciens SGBD ennuyeux .