Kürzlich war ich mit ein paar Freunden essen, die bei großen Tech-Firmen arbeiten, und irgendwie kamen wir auf das Thema Codestandards. Einer der Jungs arbeitet als Backend-Entwickler bei einem E-Commerce-Riesen in Hangzhou und erzählte, dass sein Team kürzlich eine Code-Review durchgeführt hat – mit einem verblüffenden Ergebnis: Die meisten Beanstandungen betrafen weder Logikfehler noch Performance-Probleme, sondern zu nachlässig geschriebenes SQL. Mal wurden Schlüsselwörter groß, mal klein geschrieben, die Einrückung war chaotisch, Zeilenumbrüche erfolgten nach Lust und Laune – eine etwas komplexere Abfrage wurde zu einem Labyrinth. Der Vorgesetzte ordnete sofort an: Ab jetzt muss SQL formatiert werden, wer das nicht hinbekommt, muss nachbessern.
Das ist kein Einzelfall. Ich habe mich umgehört, und Freunde bei mehreren Internetfirmen in Peking und Shenzhen berichteten, dass bei ihnen ebenfalls ernst gemacht wird. Früher war es egal, wie SQL aussah, solange es lief und das Ergebnis stimmte. Aber jetzt ist das anders – Codestandards sind von „Empfehlungen“ zu „Anforderungen“ geworden, und SQL-Formatierung wird explizit als hartes Kriterium behandelt.
Warum plötzlich dieser Ernst? Ganz einfach: Die Kosten der Teamzusammenarbeit sind zu hoch. Man stelle sich vor: Ein Projekt mit einem Dutzend Leute. Heute schreibt der eine eine dreifach verschachtelte Unterabfrage, morgen schreibt der andere einen Join mit durchgehend großen Schlüsselwörtern, und übermorgen kommt noch ein komplexer JOIN ohne Kommentare dazu. Mit der Zeit traut sich niemand mehr, die Tabelle anzufassen, und für eine Codezeile braucht man eine halbe Stunde, um zu erraten, was der ursprüngliche Autor eigentlich vorhatte. Ganz zu schweigen davon, wenn es online Probleme gibt – wer dann diesen SQL-Wust sieht, dessen Blutdruck schießt sofort in die Höhe.
Es gibt noch einen sehr praktischen Grund: Viele Unternehmen betreiben inzwischen SQL-Prüfplattformen, die den Code beim Commit automatisch scannen. Wenn das Format nicht stimmt, kommt nicht einmal der Merge-Request durch. Manche Teams haben die SQL-Formatierung sogar in die Leistungsbewertung aufgenommen – klingt übertrieben, kommt aber tatsächlich vor. Mein Freund aus Hangzhou erzählte, dass sein Team jetzt wöchentlich die SQL-Konformitätsrate auswertet, und wer wiederholt am Ende steht, muss für das ganze Team Milchtee ausgeben.
Was also tun? Man kann ja nicht jedes Mal nach dem Schreiben von SQL manuell Leerzeichen und Zeilenumbrüche anpassen – das ist zu ineffizient. Hier kommen SQL-Formatierungstools ins Spiel. Man schreibt die Anweisung, fügt sie in das Tool ein, und mit einem Klick wird das chaotische SQL übersichtlich aufgeräumt. Schlüsselwörter einheitlich groß, Einrückung ausgerichtet, Zeilenumbrüche an den richtigen Stellen, Leerzeichen dort, wo sie hingehören. Komplexe Abfragen werden automatisch in klar gegliederte Klauseln zerlegt, sodass die Logik auf einen Blick erkennbar ist.
Unterschätze das nicht. Nach der Vereinheitlichung des Formats steigt die Effizienz von Code-Reviews erheblich. Früher musste man erst fünf Minuten aufwenden, um die Struktur einer SQL-Anweisung zu verstehen; heute sieht man auf einen Blick, ob es Probleme gibt. Neue Mitarbeiter, die alten Code übernehmen, müssen sich nicht mehr mit diesem „Buch mit sieben Siegeln“ herumschlagen. Ein Freund erzählte mir sogar, dass in seinem Team nach der Einführung eines SQL-Formatierungstools die Online-Vorfälle zurückgingen, weil manche Logikfehler nach der Formatierung besonders offensichtlich wurden und sofort ins Auge sprangen.
Natürlich sind Tools nur Hilfsmittel – der Kern liegt darin, eine Gewohnheit zu entwickeln. Meine eigene Methode: Nachdem ich eine etwas komplexere SQL-Anweisung geschrieben habe, werfe ich sie zuerst in ein Formatierungstool und prüfe, ob die aufbereitete Struktur mit meiner Vorstellung übereinstimmt. Manchmal stellt sich erst nach der Formatierung heraus, dass ich eine überflüssige Verschachtelung eingebaut oder eine JOIN-Bedingung an der falschen Stelle platziert habe. Dieser Selbstcheck ist viel effektiver, als nur mit den Augen darüberzuschauen.
Letztendlich geht es bei der SQL-Prüfung in großen Tech-Firmen nicht um das Format an sich, sondern um die dahinterstehende sorgfältige Haltung. SQL ist das direkteste Werkzeug im Umgang mit Daten – wie gut es geschrieben ist, wirkt sich unmittelbar auf die Stabilität des Systems und die Effizienz der Teamzusammenarbeit aus. Früher dachte man, Hauptsache es läuft. Jetzt reicht das nicht mehr – es muss schön laufen und für andere verständlich sein.
Falls du noch kein SQL-Formatierungstool verwendet hast, empfehle ich, dir jetzt eines zu suchen und auszuprobieren. Es gibt Open-Source- und Online-Tools – such dir einfach eines aus, das dir liegt. Es kostet nur wenige Minuten, aber wenn es zur Gewohnheit wird, wirst du feststellen, dass deine SQL-Fähigkeiten ganz nebenbei eine Stufe höher steigen. Denn in diesem immer wettbewerbsintensiveren Umfeld kann man sich kaum noch als Programmierer bezeichnen, wenn man nicht einmal SQL-Formatierung im Griff hat.