Comment revoir plus efficacement les modifications SQL?
D'après mon expérience, les changements de code SQL ont presque toujours tendance à ne PAS être incrémentiels: quelqu'un crée une nouvelle procédure stockée, ou modifie une requête SQL intégrée entière à des fins d'optimisation, ou crée une toute nouvelle table. Lorsque je reçois une de ces demandes de révision de code, je n'ai pas pu trouver d'autre moyen que de comprendre la requête SQL entière. Il s'agit souvent de requêtes imbriquées très longues, appelant parfois d'autres procédures. Comprendre ces changements et les vérifier devient une tâche énorme. Ensuite, je me retrouve avec trois options:
- approuver sans examiner attentivement;
- passer beaucoup de temps pour aller ligne par ligne, comprendre le modèle de données, exécuter la requête sur un système de test pour voir ce qu'il produit;
- demandez à la personne de me guider à travers les changements.
Je ne veux pas faire 1 ou 3. Cependant, je ne veux pas non plus passer des heures à comprendre ce que fait toute la requête et si la nouvelle version est équivalente mais fonctionne plus rapidement.
Existe-t-il des technologies, des outils ou des méthodologies pour faciliter ce processus? Comment les autres effectuent-ils de tels examens sans trop souffrir?
Une différence fondamentale par rapport aux changements de code réguliers semble que les changements sql deviennent plus fréquemment (au moins conceptuellement) des réécritures entières, ce qui rend le problème plus fréquent à rencontrer - pour moi, presque chaque revue sql que je fais tous les jours.
Toutes les recommandations sont grandement appréciées.
Mise à jour:
Vous pouvez rejeter une révision ou demander à l'auteur de réécrire la modification de manière plus claire, ou ajouter d'autres commentaires ou tests. Cependant, ce que je recherche, c'est un moyen en tant qu'évaluateur de prendre réellement en charge l'examen tel qu'il est. La plupart des réponses à ce jour sur l'amélioration du changement de code afin que je puisse les consulter plus facilement. C’est évident. D'un autre côté, le problème pratique ici est que je dois aborder la revue sans la repousser à l'auteur, sans changer le comportement de l'auteur ou restructurer l'organisation.
J'espère également une recommandation spécifique à SQL, pas une recommandation générique d'examen de code. J'espère qu'il peut y avoir des outils qui aident le réviseur, peu importe à quel point la base de code est mauvaise et à quel point les pratiques d'écriture de code sont mauvaises.
Personnellement, j'ai travaillé sur de nombreuses grandes et petites entreprises en tant que développeur pendant près de 20 ans. Je maintiens des projets open source et j'ai un doctorat en informatique. J'apprécierais une aide qui en dit plus que "changer les autres et votre monde s'améliore", type de réponse non pragmatique.
Vous n'aimerez peut-être pas cela, mais:
Ce n'est pas un problème à résoudre facilement par des technologies ou des outils supplémentaires.
Un SQL qui contient "de longues requêtes imbriquées, appelant parfois d'autres procédures" et qui ne peut pas être facilement compris doit au moins avoir une indentation et des commentaires appropriés. Sinon, cela deviendra un gâchis impossible à maintenir. Donc, s'il est vraiment difficile de comprendre la requête ligne par ligne, rejetez la modification et demandez à l'auteur de la rendre plus lisible.
Et demander aux auteurs d'expliquer leur code lors d'une revue n'est pas la pire chose, bien au contraire. Vous pouvez tous les deux parcourir le code et ajouter les commentaires manquants ensemble.
Bien sûr, la solution technologique à cela serait d'éviter du tout d'écrire des requêtes SQL et de passer à quelque chose comme un ORM qui génère automatiquement la plupart des requêtes. Mais malheureusement, ce n'est pas une solution réaliste pour de nombreux systèmes du monde réel, car cela pourrait signifier de réécrire de nouvelles parties du système à partir du sol (et souvent les ORM introduisent leur propre classe de nouveaux problèmes, parfois ils introduisent plus de problèmes qu'ils ne le font résoudre).
Les requêtes SQL sont du code complexe et fragile que j'ai moi-même éprouvé comme étant assez difficile à examiner. Nous avons une bonne partie de notre base de code écrite sous forme de modèles SQL (pour de bonnes raisons, je ne m'étendrai pas dessus), donc je comprends parfaitement comment le processus de révision peut devenir difficile (et pourtant, particulièrement précieux), malgré nos efforts continus pour coder qualité.
Ce que nous avions déjà et qui nous aide un peu, c'est d'avoir des normes de code pour les requêtes SQL: niveaux d'indentation normalisés, conventions de dénomination des tables, etc.
Mais ce qui a énormément facilité le processus dans notre cas, est d'introduire des tests unitaires de toutes les requêtes SQL modifiées/nouvelles dans notre base de code avec le code à revoir. Cela vous donne un aperçu rapide de ce que la requête doit faire et vous assure qu'elle est correcte dans tous les cas. Si la suite de tests ne vous donne pas cette garantie, le code doit quand même être rejeté.
À l'heure actuelle, je lis les requêtes SQL principalement pour m'assurer que les conventions sont respectées et que les performances semblent décentes. La correction et la robustesse du code sont presque toujours mieux couvertes par une suite de tests à jour.
Je suppose que mes réflexions sur la lecture de votre question sont
- Définissez-vous ce qu'une vérification de code est censée vérifier?
- Pourquoi percevez-vous une différence entre les changements incrémentiels et non incrémentiels?
- omg arrête de mettre la logique métier dans les sprocs
Pour moi, une revue de code vérifie une liste définie de choses, y a-t-il des tests, le pipeline CI est-il configuré correctement, le guide de style est-il suivi, le travail fait-il réellement ce qui a été demandé, etc. etc. Quoi que, mais c'est une liste de vérifications qui n'importe qui peut faire n'importe quel code.
Donc, si votre changement SQL a des tests, les tests réussissent, le test couvre suffisamment de cas Edge et le code fait ce que le ticket demandait ... La révision du code a réussi!
En termes de compréhension de l'impact du changement, assurez-vous de changer le sproc que vous appelez mais pas le code sproc qui est un grand changement que vous ne pouvez pas comprendre en regardant le code.
Mais si même un petit changement de code peut tout casser, une parenthèse manquante ou une vérification nulle, un débordement d'entier, etc.
C'est pourquoi vous avez des tests. Vous n'avez donc pas à suivre le code et à déterminer s'il est correct. Vous exécutez le test et il passe ou ne marche pas et le test explique également ce que le code est supposé faire. Le sproc met à jour la commande, le bureau des retours sélect dans le monde entier, etc. Vous n'avez pas à déterminer ce que le code tente, car il est là Assert.AreEqual(results, listOfOfficesinTheWorld)
Je suppose que vous avez trop de logique dans les sprocs qui ne sont peut-être même pas en contrôle de source et n'avez pas de tests, y compris des tests de performances pour eux.
Je suggérerais que vous commenciez à déplacer la logique hors de la couche de données, à garder votre sql simple, à ajouter et à supprimer des données et à avoir la logique de manipulation dans le code avec beaucoup, beaucoup de tests unitaires.
Mise à jour en réponse aux changements:
Je pense toujours que ma réponse s'applique. Vous voulez un :
outils ou méthodologies pour faciliter ce processus (point 2)
L'automatisation du point 2 équivaut à l'écriture de tests.
comprendre le modèle de données,
Comparez les modèles de données avant et après modification. Si vous avez un test, la validation de ce test affichera le changement incrémentiel ou fondamental
exécuter la requête sur un système de test pour voir ce qu'il produit;
Exécutez le sql, comparez le résultat à celui attendu. Si vous automatisez qu'il y a votre test juste là et que la validation montrant tout changement dans le résultat attendu vous montre le changement incrémentiel ou groupé. La dénomination et les commentaires dans le test expliquent le changement EnsureCustomerIsAlwaysRight()SharesCanBeSoldInUnder100ms() etc
Attendre un outil pour écrire le test pour vous en demande un peu plus. Si votre code suit un modèle, vous pourrez peut-être créer des modèles de base. Mais le résultat attendu de vos processus va être adapté à votre application. Vous devrez toujours remplir manuellement le bit dur.
Soit échouer l'examen sur la base que ces tests ne sont pas présents, ou dans le cadre de votre processus de test manuel actuel, écrivez les tests vous-même. Ensuite, au moins la prochaine fois, votre travail sera plus facile.
Telle est la réponse pragmatique. C'est un travail difficile et prendra du temps, mais il est simple à mettre en œuvre et à comprendre, peut être mis en œuvre progressivement, vous oblige à tendre vers la séparation des préoccupations et c'est la solution normale pour résoudre ce problème commun.
Je dois être honnête; Je ne suis pas fan de ce genre de systèmes. Ils sont très difficiles à entretenir, pour plusieurs raisons que vous avez déjà articulées. Votre processus d'examen n'est pas le problème; votre architecture est le problème.
Selon moi, vos choix sont doubles:
Commencez à avoir des revues d'architecture régulièrement afin que tout le monde reste familier avec vos tables et requêtes, et fournissez une documentation et une formation adéquates qui expliquent comment tout cela fonctionne, ou
Déplacez vos requêtes simples (CRUD) vers l'application frontale ou middleware et supprimez les procédures stockées, en les réservant principalement aux opérations par lots et sur serveur.