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

Bei der Softwareentwicklung gibt es ein magisches Dreieck: Der Kunde will gleichzeitig Hohe Qualität, niedriges Budget, schnelle Fertigstellung. Es gibt ein geflügeltes Wort: Hohe Qualität, niedriges Budget, schnelle Fertigstellung - Das sind die 3 Eigenschaften, die du willst. Suche dir 2 davon aus.
Bei technologischen Schulden entschied man sich für niedriges Budget und schnelle Fertigstellung unter Aufopferung der Qualität. Faktoren, die führen zu technischer Schuld führen können, sind:
    • Unwissenheit 
    • Faulheit 
    • Zeitdruck 
    • Geldmangel
    • die bewusste Entscheidung, unreife Prototypen zu produzieren, um sie zu testen  
Technische Schulden drücken sich insbesondere durch schlecht strukturierte IT-Lösungen aus. Daraus folgen:
    • Sicherheitslücken 
    • Nach Updates funktionieren einige Dinge nicht mehr 
    • Neue Funktionen hinzuzufügen wird sehr teuer/aufwendig 
Technische Schulden muss man abbauen – aber nicht immer.
Denn der Grund, warum man Technische Schulden überhaupt macht ist, dass das Projekt schneller voran geht. Oft weiß man nicht, ob der Kunde ein Feature später behalten oder wieder wegwerfen will. Auch will man die Zeit nicht direkt investiren, alles „ordentlich“ zu machen, da man noch genügend andere Sachen zu tun hat.
Technologische Schulden fordern Zinsen, aber auch Zinseszinsen. Und genau um die Zinseszinsen soll es gehen: Ist eine Software oder ein IT-Projekt schlecht strukturiert, kann man den Fehler am Anfang noch einfach beheben. Je mehr darauf aufbaut, desto schwieriger wird es aber, die Fehler aus der Vergangenheit zu korrigieren.
So entstehen zum Beispiel auf den Provisorien weitere Übergangslösungen und Hacks, die die Komplexität des IT-Projekts unheimlich in die Höhe treiben.
Zu dem ursprünglichen Ziel, Zeit zu sparen und schnell nutzbare Ergebnisse haben, kommen nicht nur die Kosten des “Aufräumens” hinzu, sondern es werden komplett neue Systeme um das schlecht Strukturierte System herum gebaut, die im Falle einer Korrektur wieder obsolet werden – sprich: Verlust durch Abschreibung.
Für den Entwickler können wir folgende Faustregel mitgeben:
Bevor man ein System um eine Funktion erweitert, wird das System geprüft, ob es für diese neue Funktion geeignet ist oder umstrukturiert werden sollte.
Das ist zwar etwas mehr Arbeit, während der Kunde auf die schnelle Umsetzung seines Features wartet. Es lohnt sich aber: Der Implementierungsaufwand für die neue Funktion sinkt drastisch, wenn das darunterliegende System besser geeignet ist. Veranschaulicht heißt das:
Bevor man neue technologische Schulden aufnimmt, muss man die alten Kredite abbezahlen
Damit man Herr über seine Schulden bleibt, sollte man diese in einer Art „technischem Schuldenbuch“ dokumentieren. Dazu eignen sich prinzipiell zwei Techniken:
In der ersten Technik schreibst du alles, was du noch nicht implementieren willst, als Kommentar in den Code: Ausgelassene Sicherheitsprüfungen mit /* TODO: sanitizen */ - an eine Klasse konkrete Infos: TODO: Diese Klasse mit Klasse Y zu gemeinsamer Klasse Z zusammenführen.
In der zweiten Technik nutzt du dein Issue-Tracking-System, um die TODOs zu organisieren.
Wenn du ganz schlau bist, kombinierst du beide Techniken: Im Code machst du einen Kommentar TODO: #1337: Refactorn und unter der 1337 hinterlegst du dann genaue Beschreibungen, was du dort genau weggelassen hast.
Wenn dich diese Sachen weitergebracht haben, dann abonniere diesen Podcast.

Folge 10 - Technische Schulden

Carl-Philip Hänsch

Related tracks