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

Oft schaut man als Entwickler Code von früher an und fällt erst einmal aus allen Wolken: Dort ein Bug, dort schlechte Variablenbenennung, außerdem hat sich der Kunde beschwert, dass da etwas nicht funktioniert. Außerdem ist die Software-Architektur des Projekts nicht so ausgereift.

Dann überlegt man – wenn schon, dann richtig. Wäre es nicht einfach bessser, das Projekt noch mal neu zu starten und mit einem klar strukturierten Architektur anzufangen?

Kurze Antwort: Nein!

Lange Antwort: In jedem Projekt stecken, bis es wirklich funktioniert, tausende kleine Anpassungen. Natürlich gibt es eine optimale Systemarchitektur – quasi ein „Ideal“. Doch dieses Ideal erreicht man nicht, indem man das Projekt von vorn anfängt. Die Kosten dafür sind einfach zu hoch.

Was ist also die Alternative?

Die beste Lösung ist, das Projekt Stück für Stück auf die Zielarchitektur umzubauen. Dazu bedient man sich des Werkzeugkastens des „Refactorings“.

Denn Code hat immer 2 Dimensionen: Eine High-Level- und eine Low-Level-Dimension.

Arbeitet man auf der Low-Level-Dimension sauber, wird das Programm nicht abstürzen und sich in jeder erdenklichen Situation richtig verhalten. Außerdem stimmt dann auch die Performance.

Auf der High-Level-Ebene sind andere Dinge wichtig:
    • Ist die Software auf mehreren Betriebssystemen lauffähig?
    • Lässt sich die Software an neue Kundenbedürfnisse anpassen?
    • Lässt sich die Software auch für andere und ähnliche Anwendungsfälle einsetzen?
    • Lässt sich die Software gut von Menschen bedienen? UI-technisch
    • Lässt sich die Software gut von Maschinen bedienen? Ich rede hier von API-Anbindung und ähnlichem

Einfache Bugs fixt man, indem man 1-2-3 Zeilen im Code abändert. High-Level-Änderungen benötigen oft Code-Anpassungen quer über das gesamte Projekt: Umbenennungen, neue Parameter in Interfaces, neue Aufteilung von Klassen….

Oberstes Ziel eines Refactoring sollte immer sein, so viel wie möglich Code zu entfernen, ohne die Funktion des Programms dabei einzuengen. Das bedeutet in erster Linie: Code Duplication aufspüren und anhand der gefundenen Duplikate verallgemeinern.

Oft ergeben sich durch diese Zusammenführung unterschiedlichster Code-Abschnitte zu Hilfsfunktionen ganz neue Sichtweisen auf das eigene Werk: Plötzlich muss man einen neuen Namen oder Begriff für eine Funktion finden, die zum Beispiel Angebote und Rechnungen gemeinsam haben. Was haben denn Angebote und Rechnungen gemeinsam? Sie besitzen beide eine Nummer aus einem Nummernkreis, sowie eine Liste von Positionen mit jeweils Bezeichnung, Menge und Preis. Doch die Struktur allein gibt uns noch keine guten Ideen für eine Benennung der Funktion.

Wir haben die Funktion am Ende „Vertriebsvorgänge“ genannt. Dazu zählen Angebote, Rechnungen, Lieferscheine, aber auch Einkäufe / Einkaufslisten. Allein die Benennung hat uns einen unheimlichen Schub an Ideen gegeben, was Vertriebsvorgänge eigentlich alles tun können.

Einmal deduplizierter Code ist awesome. Er lässt sich nicht nur an den 2 deduplizierten Stellen verwenden, sondern man findet in der Regel noch zig weitere Anwendungsfälle für allgemeinen Code.

Noch ein Nachtrag: Ich habe vorhin behauptet, High-Level-Code-Anpassungen erstrecken sich über das komplette Projekt. Das mag stimmen für traditionelle Programmiersprachen. Es gibt aber eine neuartige Programmiersprache namens FOP, bei der ist das etwas anders – zumindest für bestimmte Fälle. Bei der FOP-Programmiersprache kann man zum Beispiel in einem einfachen 5-Zeiler dafür sorgen, dass jede Funktion, in der PDFs generiert werden, eine Kopie des PDFs in einem Dokumentenmanagement ablegen. Wie genau diese Sprache solche abstrakten Anpassungen lokal halten kann, erfahrt ihr, wenn ihr den Podcast abonniert.

Folge 7: Code neu schreiben, Projekte weiterpflegen

Carl-Philip Hänsch

Related tracks