Récemment, j'ai dîné avec quelques amis techniciens, et la conversation a dérivé sur la nouvelle politique concernant les éléments de données. Un gars qui travaille comme backend dans une entreprise de e-commerce a dit une phrase qui m'a marqué : « Les données d'interface qui circulent dans les systèmes de notre entreprise, c'est comme une station de métro à l'heure de pointe : on dirait que tout bouge, mais en réalité c'est un vrai chaos. »
C'est brut de décoffrage, mais c'est vrai. Après la mise en œuvre de la nouvelle politique, les données sont officiellement considérées comme un facteur de production. Qu'est-ce que cela signifie ? Cela signifie que ces données que vous fourriez autrefois dans une base de données, un fichier de log, ou même sur le bureau de l'ordinateur d'un collègue, doivent désormais avoir une identité officielle. En particulier pour les données d'interface, beaucoup d'entreprises ne les ont jamais gérées correctement.
Qu'appelle-t-on données d'interface ? En termes simples, ce sont les éléments échangés entre systèmes. Par exemple, après que vous passez une commande, le système de commande doit informer le système d'inventaire de déduire le stock, le système de paiement d'encaisser l'argent, et le système logistique de préparer l'expédition. Chaque transmission génère un tas de données au format JSON. Cela semble bien structuré, avec des accolades imbriquées et des paires clé-valeur bien alignées. Mais le problème, c'est qu'il y a trop de personnes qui écrivent des interfaces, chacune avec son propre style, et avec le temps, tout devient chaotique.
J'ai vu le cas le plus absurde : dans le JSON renvoyé par l'interface utilisateur d'une entreprise, l'ID utilisateur s'appelait parfois « uid », parfois « userId », et parfois « user_id ». Les développeurs front-end devaient à chaque fois consulter la documentation, puis tester, et découvrir que la documentation ne correspondait pas au retour réel. Sans parler des structures imbriquées sur sept ou huit niveaux, qui donnent mal à la tête rien qu'en les ouvrant.
C'est là que les outils de formatage JSON entrent en jeu. Ne sous-estimez pas cette fonctionnalité ; beaucoup pensent qu'il s'agit simplement de déplier une ligne JSON compressée en plusieurs lignes indentées. Quelle est la valeur technique ? Mais ceux qui ont vraiment travaillé savent combien un bon outil de formatage peut faire gagner de temps. Il permet de clarifier les relations hiérarchiques chaotiques, de voir d'un coup d'œil quel champ se trouve dans quel objet, quel tableau contient quelles propriétés. Surtout lors du débogage d'interfaces, avant et après le formatage, c'est comme deux mondes différents.
La nouvelle politique exige que les données soient gérables, traçables et évaluables. Si vous ne pouvez même pas voir à quoi ressemblent vos données d'interface, comment les gérer ? Comment les tracer ? La première étape consiste donc à rendre les données lisibles. Le formatage JSON fait exactement cela : transformer ce que la machine peut lire mais qui est pénible pour l'humain en quelque chose que l'humain peut comprendre facilement. Ce n'est pas une technologie de pointe, mais c'est le point de départ de tout travail de gouvernance des données.
Mon ami du e-commerce a ensuite instauré une règle dans son entreprise : tous les documents d'interface doivent inclure un exemple JSON formaté, et avant de soumettre le code, il faut vérifier la structure de retour avec un outil de formatage. Au début, tout le monde trouvait cela fastidieux, mais ensuite ils ont découvert que le temps d'intégration avait été réduit de moitié, et personne ne s'est plus plaint. Vous voyez, parfois, bien gérer les données n'est pas si compliqué : cela commence par une bonne utilisation d'un outil de formatage.