Folge 11 – Das CRUD-Pattern
CRUD – Alptraum und Lebenselexier jedes Entwicklers. 
CRUD steht für CREATE READ UPDATE DELETE und sind die 4 Daten-Operationen, die man einbauen muss, um eine sinnvolle Oberfläche oder API zu designen.
CREATE – irgendwie muss man den Datensatz erstellen können. Ein Anlege-Formular muss die Felder des Datensatzes leer oder mit Default-Werten gefüllt anbieten. Per Knopfdruck wird der Datensatz erstellt.
READ – Bei den Leseoperationen gibt es generell 2 Arten: Die Liste bzw. Tabelle, in der man ALLE Datensätze sieht: Tabellarisch, durchsuchbar, filterbar; Und dann gibt es noch den Detail-View, also die Detail-Ansicht. Während man in der Tabelle die Spalten weglässt, die nicht unbedingt für eine Suche oder das Wiederfinden von Datensätzen notwendig sind, sind im DetailView dann alle Daten eingeblendet. Handelt es sich im relativ einfache Datensätze wie z.B. eine einfache Relation mit 2 Spalten, kann man den DetailView auch weglassen.
UPDATE – Das Update-Formular ist wie das Create-Formular aufgebaut: Die Spalten, die man noch bearbeiten können soll, werden mit den bisherigen Daten des Datensatzes gefüllt, man bearbeitet diese und drückt auf Speichern.
Viele Entwickler versuchen, Zeit zu sparen und lassen immer wieder CRUD-Operationen weg. Meist leidet darunter die UPDATE-Funktion. Auf diese kann man noch am ehesten verzichten: anstatt einen Datensatz zu bearbeiten kann ihn ja der User löschen und neu anlegen. 
DELETE – Beim Löschen gibt man meistens dem Nutzer noch einmal die Möglichkeit, vor dem Löschen zustimmen zu müssen.
All diese 4 CRUD-Operationen für jeden Datensatz umzusetzen ist eine WAHNSINNS Arbeit.
Doch Entwickler, die auch nur eine davon weglassen, produzieren damit schlechte Software.
Als Entwickler solltest du lieber schauen, dass du dir ein einheitliches System überlegst, mit dem du für jeden beliebigen Datensatz deine CRUD-Operationen AUTOMATISCH bekommst.
Ein solches System ist die FOP-Programmiersprache. Beim FOP entwickelt man ein Datenschema und bekommt eine Oberfläche zum Manipulieren der Daten gratis dazu. Wenn du wissen willst, wie man FOP benutzt, wie man damit unheimlich schnell Web-Portale und komplexe Software-Projekte erstellt, dann abonniere diesen Podcast.

Folge 11 – Das CRUD - Pattern

Wer kennt es nicht – Studienkollegen, die damit prahlen, dass Projekt X aus hunderten Millionen Zeilen Code besteht.

Dabei habe ich nirgends im Studium gelernt, dass wir in unserem Programmiererleben so viel wie möglich Code produzieren müssen. Meine Professoren haben auf komplett andere Ziele Wert gelegt: Lesbarkeit, Wartbarkeit, Flexibilität des Codes z.B. wenn er mit anderen Datentypen verwendet wird, Wiederverwendbarkeit, Sicherheit, Korrektheit, Laufzeit-Performance uvm.

Noch besser: Angenommen, man will „sicheren Code“ schreiben, dann ist es nur hinderlich, wenn es sich um Millionen Zeilen von Code handelt. Schließlich muss man für jede einzelne Code-Zeile beweisen, dass sie das Programm nicht zu einer Fehlfunktion bringen kann.

Um die Lesbarkeit von Code zu erhöhen, kann das Programm gerne mal länger werden. Immerhin tut es dem Compiler nicht weh, wenn die Funktion „toggleFullscreen“ und nicht „tgfs“ heißt.

Doch Spaß beiseite: Die Welt benötigt nicht viel Code. Ich wette, der meiste Code in Programmen ist in Wirklichkeit kein Code, sondern es handelt sich einfach um „Daten“. Wie meine ich das?

Naja die Aufzählung von Feldern in einem Formular – dazu benötigt man keine Turing-Vollständige Programmiersprache mit Schleifen und Kontrollkonstrukten – eine JSON-Datei mit einer Liste der Felder und ihrer Datentypen, sowie 1-2 Constraints (Min-Max-Werte, Validator-Funktionen) würde genau denselben Zweck erfüllen.

Viele Programmierer schreiben diese Sachen aber in Code. Weil sie es nicht anders gelernt haben. Dabei gibt es eine einfache Grundregel, die zwar noch nie jemand genau so definiert hat, aber jeder Informatiker intuitiv im Hinterkopf hat: Schreibe den Code immer in der am wenigsten mächtigen Programmiersprache, die du verwenden kannst. Wenn ich ein String-Pattern als REGEX ausdrücken kann, brauche ich keine FOR-Schleife von Hand programmieren.

Und genau so ist es mit Millionen Zeilen Code in X-beliebigen Projekten: Trennt man dort sauber Code und Daten, hat man das Potenzial anstatt X Millionen Zeilen Code zu schreiben, lieber X Codezeilen mit Y Daten zu durchlaufen. Kann man sein Programm anstatt mit X Code in X*Y Code+Daten ausdrücken, ist X nur noch Wurzel-mal-so-groß. Bei einer Million Zeilen Code bedeutet das – Wurzel aus 1 Mio sind 1000 – 1000 Zeilen Code und 1000 Zeilen JSON-Datei.

Diese M*N-Komplexität von Code trifft man noch an anderen Stellen wieder. Ein Beispiel sind Schnittstellen-Konvertierungen. Hat man 3 Eingangs-Formate und 3 Ausgangsformate, muss man 3x3 = 9 Konvertierungsfunktionen implementieren. Führt man stattdessen ein einheitliches Zwischen-Format ein, muss man nur noch 3+3, also 6 Funktionen schreiben.

Kurzer Code hat viele Vorteile: Man ist schneller mit lesen fertig, es gibt weniger Stellen, an denen man Fehler suchen muss, man hat ihn schneller geschrieben und wenn der Kunde Änderungen wünscht, muss man weniger Code wieder löschen.

Fazit: Die eben angeschnittenen Techniken sind nur ein paar Tricks, seinen Code kurz zu halten. Es gibt noch mehr. Wenn du dran bleiben willst, abonniere diesen Podcast.

Folge 4 – Kurzer Code Ist Schön

Carl-Philip Hänsch

Related tracks