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

Viele Entwickler nutzen das Argument der Performance, um unsauberen Code zu schreiben. Ich gebe diesen Entwicklern teilweise Recht: Performanter Code benötigt manchmal die Ausnutzung sehr spezieller hardwarenaher Funktionen des Prozessors. Dem entgegen steht der Overhead, den Abstraktion bzw. sauberer Code nun einmal erzeugt.

Und trotzdem gibt es Wege heraus aus der Krise. Ein Patentrezept gibt es natürlich nicht. Das Thema ist so komplex, dass ich immer wieder mal Podcast-Folgen zu dem Thema machen werde. Wenn du also mehr darüber erfahren willst: Sauberen Code optimieren, dann abonniere diesen Podcast.

Aber steigen wir doch mal direkt ins Thema ein:

Als Einstieg etwas Altbekanntes: Sortierverfahren. Informatiker aller Welt schreiben Sortieralgorithmen wieder und wieder, weil die Abstraktionsverfahren bei den Programmiersprachen noch nicht wirklich ausgereift sind.

Klar: es hat sich eine Menge getan: Programmiersprachen mit dynamischem Typsystem und funktionalen Elementen wie JavaScript haben kein Problem mehr damit, eine einheitliche Array.sort-Funktion anzubieten.

Auch C++ punktet mit seinen statischen Templates, die keine Laufzeit- und Speicher-Overheads mehr wie JavaScript aufweisen. Dafür compiliert der Code etwas länger.

Und doch gibt es noch einige Entscheidungen, die so rein gar nichts mit der Programmlogik zu tun haben, sondern eher ein kleines Geplänkel zwischen Performance-Charakteristiken zulasten der Abstraktion sind: In C++ muss man sich festlegen, ob man die Liste als Pointer-Liste oder als komplettes Struct-Array hinterlegt. Ersteres benötigt einen ziemlichen Speicher-Overhead, ist aber schneller sortiert, letzteres ist effizienter beim Speichern, aber langsamer beim Sortieren, wenn der Struct groß genug ist.

Die anderen Programmiersprachen sind hier übrigens keinen Deut besser: Sie geben einfach eine von beiden Datenstrukturen vor und vergewaltigen dafür die Performance zugunsten der Abstraktion.

Die optimale Lösung des Problems der Abwägung Speicher vs. Performance vs. Abstraktion bei den Sortierverfahren ist jetzt nicht ganz so ganz einfach und beschäftigt Informatiker schon Jahrzehnte. Deshalb werde ich hier jetzt auch keine einfache Lösung vorschlagen.

Es gibt aber eine Menge anderer Beispiele, wo eine Performance-Optimierung, die nicht zulasten der Abstraktion gehen muss, umsetzbar ist. In den kommenden Podcast-Folgen will ich weitere solche Beispiele Stück für Stück behandeln. Vergesst also nicht, den Podcast zu abonnieren.

Folge 5 - Performance Vs Abstraktion

Carl-Philip Hänsch

Related tracks