it-swarm.com.de

Wie können SQL-Änderungen effektiver überprüft werden?

Nach meiner Erfahrung sind SQL-Code-Änderungen fast immer NICHT inkrementell: Jemand erstellt eine neue gespeicherte Prozedur oder ändert eine gesamte eingebettete SQL-Abfrage zu Optimierungszwecken oder erstellt eine brandneue Tabelle. Wenn ich eine dieser Codeüberprüfungsanfragen erhalte, konnte ich nur die gesamte SQL-Abfrage verstehen. Oft sind dies wirklich lange verschachtelte Abfragen, manchmal werden andere Prozeduren aufgerufen. Das Verstehen und Überprüfen dieser Änderungen wird zu einer großen Aufgabe. Dann habe ich drei Möglichkeiten:

  1. genehmigen, ohne sorgfältig zu prüfen;
  2. nehmen Sie sich viel Zeit, um Zeile für Zeile zu gehen, das Datenmodell zu verstehen und die Abfrage auf einem Testsystem auszuführen, um zu sehen, was es erzeugt.
  3. bitten Sie die Person, mich durch die Änderungen zu führen.

Ich möchte nicht 1 oder 3 ausführen. Ich möchte jedoch auch nicht stundenlang herausfinden, was die gesamte Abfrage bewirkt und ob die neue Version gleichwertig ist, aber schneller funktioniert.

Gibt es Technologien, Tools oder Methoden, um diesen Prozess zu vereinfachen? Wie führen andere solche Überprüfungen durch, ohne zu viel Schmerz zu erleiden?

Ein grundlegender Unterschied zu regulären Codeänderungen scheint darin zu bestehen, dass SQL-Änderungen häufiger (zumindest konzeptionell) zu vollständigen Umschreibungen werden, wodurch das Problem häufiger auftritt - für mich fast jede SQL-Überprüfung, die ich jeden Tag durchführe.

Alle Empfehlungen werden sehr geschätzt.

Aktualisieren:

Sie können eine Überprüfung ablehnen oder dem Autor mitteilen, dass die Änderung klarer geschrieben werden soll, oder weitere Kommentare oder Tests hinzufügen. Was ich jedoch suche, ist eine Möglichkeit als Rezensent, sich tatsächlich um die Rezension zu kümmern, wie sie ist. Die meisten bisherigen Antworten zur Verbesserung der Codeänderung, damit ich sie leichter überprüfen kann. Das ist offensichtlich. Andererseits ist das praktische Problem hier, dass ich die Überprüfung ansprechen muss, ohne sie an den Autor zurückzuschieben, ohne das Verhalten des Autors zu ändern oder die Organisation neu zu strukturieren.

Ich hoffe auch auf eine SQL-spezifische Empfehlung, nicht auf eine generische Empfehlung zur Codeüberprüfung. Ich hoffe, dass es möglicherweise Tools gibt, die dem Prüfer helfen, egal wie schlecht die Codebasis ist und wie schlecht die Praktiken zum Schreiben von Code sind.

Persönlich habe ich fast 20 Jahre als Entwickler in vielen großen und kleinen Unternehmen gearbeitet. Ich unterhalte Open Source-Projekte und habe einen Doktortitel in Informatik. Ich würde mich über eine Hilfe freuen, die mehr sagt als "andere verändern und deine Welt wird besser", eine nicht pragmatische Antwort.

11
CEGRD

Das mag dir vielleicht nicht gefallen, aber:

Dies ist kein Problem, das durch zusätzliche Technologien oder Tools leicht gelöst werden kann.

Eine SQL, die "lange verschachtelte Abfragen enthält, manchmal andere Prozeduren aufruft" und nicht leicht zu verstehen ist, sollte zumindest die richtigen Einrückungen und Kommentare enthalten. Andernfalls wird es zu einem nicht zu wartenden Durcheinander. Wenn es also wirklich so schwer ist, die Abfrage Zeile für Zeile zu verstehen, lehnen Sie die Änderung ab und bitten Sie den Autor, sie besser lesbar zu machen.

Und Autoren zu bitten, ihren Code während einer Überprüfung zu erklären, ist nicht das Schlimmste, ganz im Gegenteil. Sie können beide zusammen den Code durchgehen und die fehlenden Kommentare zusammenfügen.

Die technologische Lösung hierfür wäre natürlich, das Schreiben von SQL-Abfragen überhaupt zu vermeiden und zu einem ORM zu wechseln, der die meisten Abfragen automatisch generiert. Leider ist dies keine realistische Lösung für viele reale Systeme, da dies bedeuten könnte, große Teile des Systems von Grund auf neu zu schreiben (und ORMs führen häufig ihre eigene Klasse neuer Probleme ein, manchmal führen sie mehr Probleme als sie ein lösen).

11
Doc Brown

SQL-Abfragen sind komplexer und spröder Code, dessen Überprüfung für mich selbst ziemlich schwierig war. Wir haben einen guten Teil unserer Codebasis als SQL-Vorlagen geschrieben (aus guten Gründen, auf die ich nicht näher eingehen werde), daher verstehe ich vollkommen, wie der Überprüfungsprozess trotz unserer kontinuierlichen Bemühungen um Code schwierig (und dennoch besonders wertvoll) werden kann Qualität.

Was wir bereits hatten und ein bisschen helfen, sind Codestandards für SQL-Abfragen: normalisierte Einrückungsstufen, Namenskonventionen für Tabellen und so weiter.

Was den Prozess in unserem Fall jedoch erheblich vereinfacht hat, ist die Einführung von Unit-Tests aller geänderten/neuen SQL-Abfragen in unserer Codebasis zusammen mit dem zu überprüfenden Code. Auf diese Weise erhalten Sie einen schnellen Einblick in die Funktionsweise der Abfrage und können sicher sein, dass sie in allen Fällen korrekt ist. Wenn die Testsuite Ihnen diese Garantie nicht bietet, sollte der Code trotzdem abgelehnt werden.

Im Moment lese ich hauptsächlich SQL-Abfragen, um sicherzustellen, dass die Konventionen eingehalten werden und die Leistung anständig aussieht. Codekorrektur und Robustheit werden fast immer besser durch eine aktuelle Testsuite abgedeckt.

3
Arthur Havlicek

Ich denke, meine Gedanken beim Lesen Ihrer Frage sind

  1. Definieren Sie, was eine Codeüberprüfung überprüfen soll?
  2. Warum nehmen Sie einen Unterschied zwischen inkrementellen und nicht inkrementellen Änderungen wahr?
  3. omg hör auf, Geschäftslogik in Sprocs zu stecken

Für mich überprüft eine Codeüberprüfung eine definierte Liste von Dingen, gibt es Tests, ist die CI-Pipeline korrekt konfiguriert, wird der Styleguide befolgt, erledigt die Arbeit tatsächlich das, was gefragt wurde usw. usw. Was auch immer, aber es ist eine Liste von Überprüfungen, die dies tun Jeder kann mit jedem Code arbeiten.

Wenn Ihre SQL-Änderung Tests enthält, bestehen die Tests, der Test deckt genügend Edge-Fälle ab und der Code macht das, was das Ticket verlangt ... Codeüberprüfung bestanden!

Um die Auswirkungen der Änderung zu verstehen, müssen Sie den von Ihnen aufgerufenen Sproc ändern, nicht jedoch den Sproc-Code. Dies ist eine große Änderung, die Sie beim Betrachten des Codes nicht verstehen können.

Aber wenn selbst eine kleine Codeänderung alles kaputt machen kann, eine fehlende Klammer oder eine Nullprüfung, ein Ganzzahlüberlauf usw. Oder eine Änderung der Geschäftslogik, die in Bezug auf den Code korrekt erscheint, so oder so, aber eine Möglichkeit ist erforderlich.

Deshalb haben Sie Tests. Sie müssen dem Code also nicht folgen und herausfinden, ob er richtig ist. Sie führen den Test aus und er besteht oder nicht und der Test erklärt auch, was der Code tun soll . Der Sproc aktualisiert die Bestellung, das ausgewählte Rückgabebüro auf der ganzen Welt usw. Sie müssen nicht herausfinden, was der Code versucht, da er genau dort ist Assert.AreEqual(results, listOfOfficesinTheWorld)

Ich vermute, dass Sie zu viel Logik in Sprocs haben, die sich möglicherweise nicht einmal in der Quellcodeverwaltung befinden und keine Tests haben, einschließlich Leistungstests für sie.

Ich würde vorschlagen, dass Sie anfangen, Logik aus der Datenschicht zu verschieben, Ihre SQL einfach zu halten, Daten hinzuzufügen und zu entfernen und die Manipulationslogik in Code mit vielen, vielen Komponententests zu haben.

pdate als Reaktion auf Änderungen :

Ich denke immer noch, dass meine Antwort zutrifft. Du willst ein :

werkzeuge oder Methoden zur Erleichterung dieses Prozesses (Punkt 2)

Die Automatisierung von Punkt 2 entspricht dem Schreiben von Tests.

das Datenmodell verstehen,

Vergleichen Sie die Datenmodelle vor und nach der Änderung. Wenn Sie einen Test haben, zeigt das Festschreiben für diesen Test die inkrementelle oder grundlegende Änderung an

führen Sie die Abfrage auf einem Testsystem aus, um zu sehen, was es erzeugt.

Führen Sie die SQL aus und vergleichen Sie das Ergebnis mit den erwarteten. Wenn Sie automatisieren, dass Ihr Test genau dort ist und das Commit eine Änderung des erwarteten Ergebnisses anzeigt, zeigt es Ihnen die inkrementelle oder gruppierte Änderung an. Namen und Kommentare im Test erklären die Änderung EnsureCustomerIsAlwaysRight()SharesCanBeSoldInUnder100ms() etc.

Zu erwarten, dass ein Tool den Test für Sie schreibt, ist ein bisschen viel verlangt. Wenn Ihr Code einem Muster folgt, können Sie möglicherweise einige grundlegende Dinge vorlegen. Das erwartete Ergebnis Ihrer Prozesse wird jedoch auf Ihre Anwendung zugeschnitten. Sie müssen das harte Bit immer manuell ausfüllen.

Führen Sie die Überprüfung entweder nicht durch, weil diese Tests nicht vorhanden sind, oder schreiben Sie die Tests im Rahmen Ihres aktuellen manuellen Testprozesses selbst. Dann ist zumindest beim nächsten Mal Ihre Arbeit einfacher.

Dies ist die pragmatische Antwort. Es ist harte Arbeit und wird einige Zeit in Anspruch nehmen, aber es ist einfach zu implementieren und zu verstehen, kann schrittweise implementiert werden, zwingt Sie zur Trennung von Bedenken und es ist die normale Lösung, um dieses häufige Problem zu beheben.

2
Ewan

Muss ehrlich sein; Ich bin kein Fan dieser Art von Systemen. Sie sind aus mehreren Gründen, die Sie bereits angesprochen haben, sehr schwer zu warten. Ihr Überprüfungsprozess ist nicht das Problem. Ihre Architektur ist das Problem.

Aus meiner Sicht haben Sie zwei Möglichkeiten:

  1. Beginnen Sie regelmäßig mit Architekturprüfungen, damit jeder mit Ihren Tabellen und Abfragen vertraut ist, und stellen Sie eine angemessene Dokumentation und Schulung bereit, in der erklärt wird, wie alles funktioniert, oder

  2. Verschieben Sie Ihre einfachen (CRUD) Abfragen an die Front-End- oder Middleware-Anwendung und beseitigen Sie die gespeicherten Prozeduren, indem Sie diese hauptsächlich für Batch- und Server-Vorgänge reservieren.

1
Robert Harvey