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.

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.

Quellcode kann unheimlich redundant sein. Wir haben bereits in einer älteren Folge darüber gesprochen, dass man durch geschicktes Refactoring Code-Duplikation entfernen kann.

Quellcode ist Information. Wenn ich in der Lage bin, ein- und dasselbe Programm einmal mit 1000 Zeilen Code und einmal mit 300 Zeilen Code zu implementieren, dann hat das Programm nur einen Informationsgehalt von 300 Zeilen! Kurzer Code ist schön. Die restlichen 700 Zeilen verkomplizieren das Programm nur.

Dabei gehe ich von sauber geschriebenem Code aus und zähle die Kommentare nicht als Codezeilen mit. Es geht rein um die Anzahl an Anweisungen, Ausdrücken, Schleifen und Funktionen im Code.

In der Folge 4 „Kurzer Code ist schön“ habe ich bereits angedeutet, dass zum einen weniger Code weniger Probleme bedeutet: Weniger Bugs, weniger Code zu warten, weniger Code zu lesen. Außerdem habe ich eine Technik vorgestellt, mit der man durch ein Zwischen-Interface aus m*n Codezeilen m+n Codezeilen umschreiben kann.

Diesmal geht es um eine andere Technik: Projektübergreifendes Refactoring.

Projektübergreifendes Refactoring ist das mächtigste Werkzeug, wenn man jedes einzelne Projekt mit minimalem Aufwand umsetzen will.

Diese Folge in meinem Programmier-Podcast ist heute ein bisschen anderer Natur. Ich will euch zeigen, wie einfach es ist, sein eigenes Git-Hosting und Projekttool zu entwickeln.

Git ist aus der heutigen Programmierlandschaft nicht mehr wegzudenken. Früher hat man ZIP-Dateien mit Quellcode per E-Mail versandt, wenn man im Team arbeiten wollte. Dann gab es das erste Versionskontrollsystem: CVS. Man konnte Ordner für seine Kollegen sperren. Damit waren schon mal Konflikte unter Kontrolle, dass zwei Nutzer dieselbe Datei bearbeitet haben. Bei der Freigabe der Datei wurde dann die neue Version der Datei verteilt. Blöd nur, wenn der Kollege, der eine Datei gesperrt hat, gerade im Urlaub war.

Es gibt 1-2 Self-Hosting Git-Tools, z.B. das auf Go basierende Gogs, welches wir verwendet haben. Außerdem gibt es in der Cloud noch github.com von Microsoft.

Uns hat das Gogs irgendwann nicht mehr ausgereicht, Alternativen waren zu klobig und mit Features überladen und in die Github-Cloud wollten wir auch nicht mit unseren Firmendaten.

Die Anforderungen an ein neues Git-Tool waren:

• Projektübergreifende Issues, die man von egal-welchem Projekt lösen konnte

• Suchfunktion für Issues

• Kunden-Zugriff mit sichtbaren und unsichtbaren Issues

• Eine intelligente Issue-Priorisierung – wir haben uns entschieden, die Priorität in € zu messen

• Issue-Abhängigkeiten und damit verbundene Priority inheritence: Die Priorität einer Issue in € wird einfach auf die abhängigen Flaschenhals-Issues aufaddiert

Ein eigenes Git-Tool ist im Prinzip nicht schwer zu bauen. Man benötigt einen SSH-Server, auf den man pushen und von dem man pullen darf, sowie ein Web-Frontend für das Projektmanagement und die Issues.

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.

Stell dir vor, du hast zwei Tabellen, die in einer 1:n-Relation miteinander verbunden sind. Nehmen wir als Beispiel die Bestellungen und die Bestellpositionen. Jeweils eine Bestellung hat mehrere Bestellpositionen.

Wenn du jetzt eine Anwendung bauen musst, die sowohl eine Liste mit Bestellungen durchläuft, zu jeder Bestellung aber auch noch die Bestellpositionen abklappert, kommst du bei ausreichend Datenmenge ziemlich schnell an die Leistungsgrenzen deiner Programmiersprache.

Das Problem: Wahrscheinlich implementierst du einfach zwei verschachtelte Schleifen. In der äußeren Schleife durchläufst du die Bestellungen, in der inneren Schleife durchläufst du die Bestellpositionen. Dabei benötigst du für die erste Schleife genau EINEN SQL-Query-Aufruf, um die Bestellungen aufzulisten. Für die Bestellpositionen wird jedoch JE BESTELLUNG EIN SQL-Query-Aufruf für alle Positionen einer Bestellung aufgerufen.

SQL Queries in Schleifen sind IMMER eine Dumme Idee. Jeder SELECT-Aufruf ist in der Lage, mehrere Ergebnisse zurückzuliefern, also nutze das, um ALLE Ergebnisse mit einer Query zu erlangen.

Willst du weitere solche Tipps zur Optimierung erlernen? Dann abonniere doch einfach diesen Podcast.

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.

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.

Vorstellung ERPL (https://www.erpl-software.de/)

Hallo ich bin ERICH ERPL. Ich bin Influencer bei Launix, aber das könnt ihr alles auf meinem Blog nachlesen. Weshalb ich eigentlich zu euch spreche: Der Chef hat mich dazu gezwungen, ein bisschen Werbung für seine blöde Software zu machen, sonst bekomme ich nix zu essen. Also dann mal los.

ERPL ist eine Software, mit der man seine Firma einfach und unkompliziert verwalten kann. Das StartERPaket enthält Angebote, Briefe und Rechnungen, Bank-Anbindung und Mahnwesen. Beim ERPL Line kommt noch eine Warenwirtschaft hinzu mit Bestellungen, Lieferscheinen und Einkaufswesen inklusive E-Mail-Preisanfrage an gleich mehrere Anbieter. Dann gibt es noch ERPL Home für die Dokumentenverwaltung zu Hause und ERPL Sport für die Verwaltung von Vereinen. Die letzten beiden hat der Chef aber noch nicht mal fertig, sucht aber jetzt schon Leute, die blöd genug sind, das zu testen. Sonst noch was?

Ich hasse meinen Job. Kann ich jetzt gehen?

Nein

Also was noch?

Du sagst noch, das die Software gut ist und dass die Zuhörer sie kaufen müssen

Okay… Die Software ist gut. Kauft sie. Fertig?

Nein, das war nicht ehrlich gemeint.

Okay Okay. Kauft sie! Sonst passiert mir hier noch was! Geht das so?

Ja, das war ehrlich.

Software – insbesondere große Projekte – sind die Hölle, wenn man den kompletten Code von Hand schreibt. Durch diese Hölle müssen aber die meisten Projekte durch, weil sie eine Technik noch nicht kennen oder können. Die Rede ist von Software Composition.

Software Composition ist ureigens erst einmal das Zusammensetzen, also „Komponieren“ von Software. Wozu tut man das? Um Crosscutting Concerns zu entflechten. Das bedeutet, man steigert die Wiederverwendbarkeit seines Codes, indem man ihn unabhängig vom aktuellen Projekt programmiert.

Um das ganze etwas anschaulicher zu machen nehmen wir mal das Beispiel „Logging“. Traditionell programmiert würde man den Logging-Code quer über sein Projekt verteilen. Das macht die bisherigen Funktionen schwerer lesbar, weil überall Log-Aufrufe verstreut sind – und das Logging nur EIN Aspekt der kompletten Software ist. Wenn noch Aspekte wie Zugriffsregeln, Persistenz und Transaktionsfähigkeit hinzukommen, behandelt nur noch ein kleiner Teil des Codes wirklich die aktuelle Geschäftslogik.

Noch schlimmer: Lernt man neue Programmierer ins Projekt ein, müssen diese erst einmal die „Hygieneregeln“ des Codes kennen lernen: Wie greift man auf das Zugriffsregel-System zu, welche Ereignisse muss man loggen, wie verwendet man das Transaktionssystem.

Software Composition versucht jetzt, diese sich überlappenden Aspekte zu entflechten. In dem einen Stück Code soll nur die Geschäftslogik programmiert werden. Ein anderes Stück Code soll für alle Funktionen die Zugriffsrechte einstellbar machen – z.B. durch eine Zugriffsmatrix. Entflechten heißt hier wirklich physisch: sie auf mehrere Dateien aufteilen, damit jemand, der den Zugriffs-Code baut, sich nicht um das Logging kümmern muss.

Fazit: Software Composition ist ein mächtiges Werkzeug, um komplexen Code zu entflechten. Es ermöglicht, eine komplexe Software im Code einfach zu halten, auch wenn viele Aspekte aufeinanderprallen. Wenn du mehr über Kompositionstechniken erfahren willst und wie man diese konkret umsetzt, abonniere diesen Podcast.