Sphera
Développeur de données
Réduction de 30 % du temps de build de production en réécrivant le SQL qu'un ORM générait silencieusement
Spécifications de mappage C# et Entity Framework, réécrites pour que le SQL généré ressemble à ce qu'un DBA recommanderait vraiment. Intégrité des données vérifiée avant et après pour que le gain ne change pas silencieusement le comportement.
Le problème
Les builds de production étaient assez lents pour nuire à la productivité de toute l'équipe de développement. La couche d'accès aux données existante faisait plus d'allers-retours que les requêtes ne l'exigeaient, et la forme de requête par défaut générée par Entity Framework n'était pas celle qu'un DBA aurait écrite à la main.
L'approche
Développement de spécifications de mappage en C# avec Entity Framework pour optimiser le motif d'accès aux données.
Lecture du SQL réellement généré par Entity Framework en coulisses, réécriture des mappages pour que la sortie ressemble à ce qu'un DBA approuverait, et utilisation de requêtes SQL efficaces pour maintenir et vérifier les données.
Vérification de l'intégrité des données avant et après chaque changement pour que l'optimisation ne change pas silencieusement le comportement.
Le résultat
Temps de build de production réduit de 30 %.
Efficacité globale du développement logiciel améliorée.
Équivalence comportementale maintenue sur la surface d'accès aux données modifiée.
Ce que j'en retiens
Les ORM génèrent silencieusement la requête qu'ils vont générer, que la forme soit bonne ou pas. Le 30 % venait de la lecture du SQL réel, pas du C# qui l'avait produit. La même leçon s'applique au code généré par un LLM aujourd'hui : lisez la sortie, pas juste l'invite.