Récemment, j'ai dîné avec quelques amis qui travaillent dans de grandes entreprises, et la conversation a dérivé sur les normes de code. L'un d'eux, qui fait du backend dans un géant du e-commerce à Hangzhou, a raconté que son équipe avait récemment fait une revue de code, et le résultat a été surprenant : ce qui posait le plus de problèmes n'était ni les failles logiques, ni les problèmes de performance, mais le SQL écrit trop négligemment. Mélange de majuscules et de minuscules dans les mots-clés, indentation chaotique, retours à la ligne aléatoires, une requête un peu complexe devenait un labyrinthe. Le chef a immédiatement tranché : désormais, le SQL doit être formaté, sinon il est renvoyé pour réécriture.
Ce n'est pas un cas isolé. J'ai demandé autour de moi, et plusieurs amis dans des entreprises internet à Pékin et Shenzhen ont dit que chez eux aussi, on commençait à sévir. Avant, tant que le SQL tournait et donnait le bon résultat, personne ne se souciait de son apparence. Mais maintenant, ce n'est plus pareil : les normes de code sont passées de « recommandation » à « exigence », et le formatage SQL est devenu un critère strict à part entière.
Pourquoi soudainement tant de rigueur ? En clair, le coût de la collaboration en équipe est devenu trop élevé. Imaginez : un projet avec une dizaine de personnes, aujourd'hui l'un écrit une sous-requête imbriquée sur trois niveaux, demain l'autre écrit une jointure avec tous les mots-clés en majuscules, après-demain encore un autre pond une jointure complexe sans aucun commentaire. Avec le temps, plus personne n'ose toucher à cette table, et modifier une ligne de code prend une demi-heure à deviner ce que l'auteur voulait faire. Sans parler des incidents en production : quand on doit diagnostiquer un problème et qu'on tombe sur ce tas de SQL, la tension monte d'un coup.
Il y a aussi une raison très concrète : beaucoup d'entreprises mettent en place des plateformes d'audit SQL qui scannent automatiquement le code au moment du commit. Si votre format n'est pas conforme, même la demande de fusion ne passe pas. Certaines équipes ont même intégré le formatage SQL dans l'évaluation de performance, ce qui peut sembler exagéré, mais c'est bien réel. Mon ami de Hangzhou raconte que son équipe calcule chaque semaine le taux de conformité SQL, et ceux qui sont derniers doivent offrir le thé à toute l'équipe.
Alors que faire ? On ne va quand même pas ajuster manuellement les espaces et les retours à la ligne après chaque requête, c'est trop inefficace. C'est là que les outils de formatage SQL entrent en jeu. Vous écrivez votre requête, vous la collez dans l'outil, et en un clic, le SQL chaotique devient propre et clair. Mots-clés en majuscules uniformes, indentation alignée, retours à la ligne aux bons endroits, espaces ajoutés là où il faut. Les requêtes complexes sont automatiquement décomposées en clauses distinctes, et la logique saute aux yeux.
Ne sous-estimez pas ce geste. Une fois le format uniformisé, l'efficacité des revues de code augmente considérablement. Avant, pour relire une requête SQL, il fallait d'abord passer cinq minutes à comprendre la structure ; maintenant, un coup d'œil suffit pour voir s'il y a un problème. Les nouveaux qui reprennent du code ancien n'ont plus à affronter ces « hiéroglyphes ». Un ami m'a même dit que depuis que son équipe utilise un outil de formatage SQL, les incidents en production ont diminué, car certaines erreurs logiques deviennent flagrantes après formatage, visibles au premier coup d'œil.
Bien sûr, l'outil n'est qu'une aide ; l'essentiel est de prendre l'habitude. Ma méthode : après avoir écrit une requête un peu complexe, je la passe dans l'outil de formatage pour voir si la structure obtenue correspond à ce que j'avais en tête. Parfois, après formatage, je découvre que j'avais écrit une imbrication superflue ou mal placé une condition de jointure. Cet auto-contrôle est bien plus efficace que de simplement vérifier à l'œil nu.
En fin de compte, quand les grandes entreprises vérifient les normes SQL, ce n'est pas le format en soi qu'elles contrôlent, mais l'attitude rigoureuse qu'il représente. Le SQL est l'outil le plus direct pour interagir avec les données ; sa qualité affecte directement la stabilité du système et l'efficacité de la collaboration. Avant, on se contentait que ça tourne ; maintenant, non, il faut que ce soit beau et compréhensible par les autres.
Si vous n'avez pas encore utilisé d'outil de formatage SQL, je vous conseille d'en essayer un dès maintenant. Il y en a des open source et des en ligne, choisissez celui qui vous convient. Ça ne prend que quelques minutes, mais une fois l'habitude prise, vous verrez votre niveau de SQL monter sans vous en rendre compte. Après tout, dans cet environnement de plus en plus compétitif, si on ne sait même pas gérer le format de son SQL, c'est difficile de se dire développeur.