Wann, wenn überhaupt, können Codestandards ignoriert werden? [geschlossen]

Mein Unternehmen hat beschlossen, gespeicherte Prozeduren für alles zu verwenden, was mit der Datenbank zu tun hat (weil sie außer Raw SQL keinen anderen Weg kannten), und wie das Sprichwort sagt "When in Rome ...", versuche ich zu folgen. Vor kurzem musste ich einen Hack-Fix hinzufügen, der das Abrufen eines Datenbankwerts erforderte, und da es sich um einen einzelnen Wert aus einer einzelnen Tabelle handelte, schrieb ich ihn als Inline-SQL (natürlich parametrisiert), da anscheinend kein a erforderlich war gespeicherte Prozedur für eine triviale Codezeile, die in einem einzelnen Teil der Anwendung als Kludge verwendet wird.

Natürlich wurde mir jetzt gesagt, ich soll das Problem beheben und Stored Procs immer nur für alles verwenden, was mit der Datenbank zu tun hat. Das fühlt sich einfach ein bisschen zu sehr an, als würde man blind dem Dogma folgen, anstatt den gesunden Menschenverstand zu verwenden. Versteh mich nicht falsch, ich verstehe den Zweck von Kodierungsstandards, aber ich bin auch ein Befürworter des Ignorierens von Standards, wenn sie keinen Sinn ergeben, und folge ihnen nicht nur blind, als wären sie Evangelium.

Codestandards sind normalerweise nur Richtlinien. Es hört sich jedoch so an, als hätte Ihr Unternehmen eine Richtlinie, und Richtlinien können normalerweise nicht ignoriert werden. Wenn Sie es angesprochen haben und stattdessen aufgefordert wurden, ein gespeichertes Verfahren zu verwenden, würde ich dies tun, obwohl ich eine andere Entscheidung treffen würde, wenn ich die Berechtigung dazu hätte.

Ich denke, sie versuchen tatsächlich, den Vertrag zwischen dem App-Code und der Datenbank zu trennen. Wenn sie beispielsweise jemals einen Spaltennamen ändern müssten, müssten sie nur sicherstellen, dass die Verträge (SPs) funktionieren.

Get_Costumer () oder was auch immer ist eine Möglichkeit, den App-Code von der Struktur der Datenbank zu abstrahieren, und meiner Meinung nach ist dies eine echte Best Practice, die Sie in Betracht ziehen sollten. Architektonisch möchten Sie fast immer, dass Ihr DB- und App-Code entkoppelt wird.

Es mag auf den ersten Blick übertrieben erscheinen, solche Richtlinien so streng zu betrachten, aber ich denke, es ist wichtig, sich an Richtlinien zu halten, es sei denn, Sie haben einen sehr guten Grund . Ich sage das wegen der Theorie der zerbrochenen Fenster . Dies gilt insbesondere dann, wenn Sie Nachwuchsentwickler haben, die noch die bewährten Methoden und Gewohnheiten benötigen.

Ist die Tatsache, dass Ihr Fix schnell war oder ein Hack wirklich ein guter Grund, ein Fenster zu brechen?

Stellen Sie sich einen unerfahrenen Entwickler vor, der Ihren Code verwaltet. Vielleicht ändern sie die Abfrage oder fügen eine andere auf ähnliche Weise hinzu, und plötzlich gibt es einen Sicherheits-Exploit, weil sie nicht erkannt haben, dass das Ändern der Abfrage auch das Ausführen der Ausführung erfordert.

Hinweis: Es ist ein separates Problem, ob die Richtlinien Dinge sind, die immer an erster Stelle verwendet werden sollten. Dies ist jedoch ein Problem, das beim Festlegen der Richtlinien berücksichtigt werden muss. Mein Punkt ist, dass es wichtig ist, sich an Dinge zu halten, die immer gut sind, wenn Sie sich für Dinge entschieden haben, die immer gut sind.

Rückblick auf andere Antworten

Hier ist eine kurze Zusammenfassung dessen, was andere hier zuvor gesagt haben.

Pro Unternehmenspolitik:

• Ermöglicht das Verfolgen von Abhängigkeiten zwischen Datenbankobjekten und die Übersicht darüber, wie sich geplante Änderungen auf das Schema auswirken.
• Das DBA-Team kann die Zugriffsrechte für Anwendungen überprüfen und steuern.
• Das DBA-Team kann die Auswirkungen von Änderungen auf die Leistung vorhersagen.
• Entkoppelt Datenbank vom Anwendungscode;
• Theorie des zerbrochenen Fensters ... das heißt, auf diese Weise organisieren sie ihren Code, und wenn die Konsistenz gebrochen wird, ist die Infrastruktur für Neuankömmlinge schwerer zu erfassen, wodurch sie weniger Respekt haben und weniger nach Qualität streben.
• Sie erhalten Ihren Gehaltsscheck, um das zu tun, worum Sie gebeten wurden. Dies ist eine Unternehmensrichtlinie, und Sie sind derzeit nicht befugt, diese zu ändern. Leben Sie also besser damit.

Gegen Unternehmenspolitik:

• Diese Unternehmensphilosophie ist sehr starr und dogmatisch, und die Richtlinien machen die Arbeit der Entwickler unnötig umständlich. Siehe leider den letzten Punkt im Abschnitt "Profis".
• Da back2dos darauf verweist, indem es sagt: "Für jede Abfrage an die Datenbank müssen Sie die gespeicherte Prozedur nachschlagen " , führt eine Nur-Sprocs-Richtlinie häufig zu einer Codeduplizierung, da verschiedene Entwickler keine Ahnung haben, welche Sprocs für ihre wiederverwendet werden könnten Problem zur Hand;
• Ironischerweise verursacht das Gegenteil zum vorherigen Fall auch Probleme, wenn eine Anwendung einen Sproc besitzt, eine andere ihn wiederverwendet und die erste ihn aktualisiert, ohne zu wissen, wer sich sonst darauf verlassen hat. DBAs verfolgen die Abhängigkeiten nicht weiter als bis zu den Wänden des DB-Serverraums. Erwarten Sie also nicht, dass es ihnen egal ist, welche App von was außerhalb davon abhängt. Wenn die Anwendungsteams es nicht untereinander verfolgen, was ihr Problem ist, werden die Datenbankadministratoren abgedeckt.

DIESE 2 CENT

Erstens verwenden viele Antworten hier das Wort Standard . Die Praxis, direkte Abfragen zu verbieten und nur Sprocs zuzulassen, wird nicht als Standard bezeichnet. Es ist eine Politik (siehe die Antwort von jzd ).

Zweitens, spezifisch für Ihr Problem: Mein Hauptgegenargument gegen eine solche restriktive Richtlinie, ausschließlich gespeicherte Prozeduren zu verwenden, wäre die SQL-Sprache selbst und nicht unbedingt die zentralisierte Repository-Infrastruktur für Geschäftslogik, die sie fördert (obwohl dies auch Gegenargumente hat). .

SQL ist eine ziemlich starre und nicht zusammensetzbare Sprache mit sehr begrenzter Ausdruckskraft . Dies bedeutet, dass Sie in Bezug auf die Wiederverwendbarkeit von Code sehr früh in eine Sackgasse geraten . Einer der Gründe für diese Starrheit ist, dass es keine Möglichkeit gibt, erstklassige Funktionen in irgendeiner Weise zu übergeben (wie bei OOP-Sprachen, die Polymorphismus verwenden), was die Kompositionsfähigkeit erheblich einschränkt . Das, was Sie an Ausdruckskraft am nächsten bringen können, ist das Schreiben dynamischer SQL-Abfragen, die mithilfe der Zeichenfolgenverkettung erstellt wurden. Keine nette Sache. Dynamische Abfragen beseitigen einige der Punkte im Abschnitt "Profis", wie z. B. die Tracking-Abhängigkeiten zwischen DB-Objekten, und weisen normalerweise eine schlechtere Leistung auf, sind fehleranfällig, schwer zu debuggen und erhöhen dieRisiko von SQL-Injection-Angriffen . Leider werden Sie mit SQL feststellen, dass Sie mit dem Extrahieren gemeinsamer wiederverwendbarer Logik zwischen Sprocs nicht weit kommen können, ohne die Wand zu treffen und gezwungen zu sein, auf dynamisch ausgeführte Abfragen zurückzugreifen.

UPDATE: Eine weitere große Einschränkung gespeicherter Prozeduren neben der erstklassigen Funktion ist das Übergeben und Zurückgeben von zusammengesetzten Datentypen als Argumente, unabhängig davon, ob es sich um Listen, Mengen, Datensätze oder Schlüssel-Wert-Paare handelt. Dies schadet der Kompositionsfähigkeit ebenfalls sehr.

Schließlich stimme ich nicht unbedingt einem der oben genannten Pro- Punkte zu, der "Entkopplung der DB von der Anwendung" von Jorge : Das Hauptprinzip, das meiner Meinung nach hier gilt, besteht darin, primitive Datenstrukturen mit einer großen Anzahl gemeinsamer wiederverwendbarer und zusammensetzbarer Operationen zu bevorzugen. anstatt mit benutzerdefinierten APIs zu arbeiten . Sprocs sind hier solche benutzerdefinierten APIs , die zwischen dem Benutzer und den primitiven relationalen Daten stehen, um sie unter Verwendung allgemeiner Grundelemente für die Manipulation zusammensetzbarer Daten abzufragen ( auswählen, verbinden, wo, gruppieren nach, usw). Jetzt ist SQL selbst aufgrund der oben genannten Starrheit nicht die ideale Wahl, um DSL für zusammensetzbare Datenmanipulationsprimitive zu sein, aber mit einer vernünftigeren Sprachwahl (wie .NET Linq ... oder Lisp / Clojure!) Könnten Sie Ihre ausführen Logik gegen eine einfache Liste genauso wie gegen ein DB ResultSet. Das macht es natürlich leicht testbar, was eine gute Sache ist. Ich sage, bevorzugen Sie, dass Ihr Datenspeicher einfach und primitiv dumm ist, so dass er mit einfachen CSVs gestoppt werden kann. Wie Sie sehen, entkoppelt dieses Modell auch DB von der Anwendung, nur zeichnet es die Linie auf einer niedrigeren Abstraktionsebene.

WAS MACHT MAN ALS NÄCHSTES?

Es hat etwas nichts mit der Frage zu tun , aber ich empfehle Ihnen, einen Blick auf Datomic zu werfen , das einen interessant neuartigen Ansatz zum Speichern und Abfragen von Daten gemäß einigen der obigen Beobachtungen bietet. (Natürlich, ich meinen Blick auf mich streng außerhalb der Arbeitsumgebung zuerst ... auf jeden Fall tue NICHT gehen in das Büro des CTO am nächsten Tag und sagen : „Hey Jungs , die ich einige Ihrer sprocs in Datomic neu geschrieben und es auf diesem glänzenden prod Server über im Einsatz dort ist es wirklich cool, schau mal! " Sie werden die sonst völlig verständliche Aufregung vielleicht nicht zu schätzen wissen;)

Der einzige Ort, an dem ich Codierungsstandards routinemäßig ignoriere, ist automatisch generierter Code. Andernfalls wird er normalerweise von Fall zu Fall behandelt und in einer Codeüberprüfung doppelt überprüft. Sie können kein Sklave von Codierungsstandards sein, aber Ausnahmen sind meiner Erfahrung nach ziemlich selten.

Wenn Sie keine gespeicherten Prozesse verwenden, nimmt Ihr dbas Änderungen an der Datenstruktur vor, ohne zu wissen, welche Auswirkungen sie auf Ihren Inline-Code haben könnten, von dem er nichts weiß. Es ist ein großes Problem für die Wartung, wenn ein Cowboy-Codierer nicht dem Design folgt. Hier geht es nicht um Codierungsstandards - hier geht es um das Design. Sie müssen das Design nicht immer mögen oder ihm folgen wollen, aber es ist nicht Ihre Aufgabe, also tun Sie einfach, was Sie tun sollen. Ich würde dir einen kostenlosen Pass für so etwas geben und dich dann feuern.

Als langjähriger Programmierer und Teamleiter muss ich in der Lage sein, über den Tellerrand hinaus zu denken. Codierungsstandards helfen dabei, die Dinge schön zu halten, aber wenn sie im Weg sind, kann es eine Hölle geben, die zu bezahlen ist. In diesem Fall hängt es von ihrer Definition des Verfahrens ab. Wenn es restriktiv statt freizügig ist, müssen die Leads zeigen, wo es Probleme gibt.

Die Codequalität kann an ihrer Lesbarkeit gemessen werden. Sie möchten sich den Code ansehen und sehen, was er bewirkt.

Bei Codierungsstandards geht es darum, die Lesbarkeit im gesamten Team zu verbessern, da Sie den Code eines Kollegen überprüfen und sehen möchten, was er tut.
Im Idealfall führt dies zu Code, den jeder lesen kann. Es ist, als würde man erwarten, dass die Leute sauberes Englisch sprechen, anstatt mit ihrem eigenen Akzent herumzumurmeln und mit einem anständigen Maß an Rechtschreibung und Grammatik zu schreiben, anstatt alles in lolcat- oder leetspeek zu schreiben.

Was Ihr Unternehmen als Standard konzipiert hat, erzwingt nicht die Lesbarkeit im gesamten Team, sondern reduziert sie. Für jede Abfrage an die Datenbank müssen Sie die gespeicherte Prozedur nachschlagen.
Dies ist so, als würde man erwarten, dass die Leute keine normalen Sätze wie "Möchtest du Kaffee?" Sagen. zu sagen "Sie haben eine E-Mail mit dem Betreff" Kaffee "in Ihrem Posteingang" für die normale Kommunikation. Dies erhöht das Verständnis in Ihrem Team nicht, da die gespeicherte Prozedur (oder der Inhalt der E-Mail) nur ein komplettes Hokuspokus sein kann.

Es ist also kein (vernünftiger) Kodierungsstandard, sondern nur eine blöde Formalität. Der einzige Punkt bei dummen Formalitäten ist, dass sie dazu beitragen, die Menge an Scheiße zu begrenzen, die eine Person pro Zeit erzeugen kann, aber sie behindern Menschen, die einen tatsächlichen Beitrag leisten müssen.

Sie sollten versuchen, mit dem zu sprechen, der dafür verantwortlich ist (und viel höflicher sein als ich;)).

Wenn Sie es einfach nicht zum Laufen bringen können, haben Sie wahrscheinlich Ihre Ausnahme gefunden. Irgendwann stellt das Team fest, dass Sie eine dokumentierte Ausnahme machen, wenn Sie dies im Rahmen Ihrer Standards tun, einfach zu viel Aufwand betreiben oder eine schlechte Lösung erstellen. Sie ändern die Standards, wenn dies zu oft vorkommt.

Sie verwenden dies nur als Beispiel, aber ist es wirklich so schwierig, eine select-Anweisung in eine gespeicherte Prozedur zu verpacken? Sie bekommen offensichtlich viel Übung in Ihrem Geschäft. Es gibt andere Standards, die wahrscheinlich schwieriger zu befolgen sind. Ich weiß nicht, warum Programmierer dies nicht lieber an eine Datenbank weitergeben würden (ich weiß, nicht Ihr Fall). Persönlich sieht SQL in den meisten Programmierideen wie Mist aus, aber wie alles andere gewöhnt man sich daran oder beginnt mit der Verwendung von ORM.

Standards können unter folgenden Umständen ignoriert werden:

Wenn Sie mit Ihren Entwicklerkollegen gesprochen und eine Einigung erzielt haben oder eine Richtlinie festgelegt haben, die durchgesetzt werden soll, oder wenn Ihr Unternehmen entscheidet, dass die Nichteinhaltung von Standards die richtige Geschäftsentscheidung ist (z. B. stehen möglicherweise Millionen von Dollar an ein Fix "jetzt", unabhängig davon, ob es mit Standards in Konflikt steht).

Dies gilt für Regeln, wenn;

• Sie wurden ignoriert und bis zu einem Punkt missbraucht, an dem ein großer Teil des Codes ihnen nicht mehr folgt.

• Es gibt mehrere konkurrierende Standards, und es ist nicht klar, welche anzuwenden sind.

• Der lokale Standard widerspricht dem Industriestandard, z. B. sagt ein Unternehmen, dass wir 9 Leerzeichen zum Einrücken (!) verwenden.

Aber auch in den obigen drei Beispielen lautet die GOLDENE Regel, wann immer möglich, dass Sie ZUERST mit allen Beteiligten sprechen. Zumindest (z. B. um 2 Uhr morgens) sollten Sie Ihre Entscheidung so schnell wie möglich besprechen - und darüber diskutieren, und nicht nur Informationen darüber senden, was Sie getan haben. Seien Sie bereit für Kritik und Änderungen.

Es ist immer in Ordnung, Codierungsstandards zu verletzen. Wenn Sie dies tun, sollten Sie jedoch immer einen Kommentar schreiben, in dem erwähnt wird, dass der Verstoß absichtlich war, und eine Art Rechtfertigung angeben.