Pro-Grammierer-Podcast

About Pro-Grammierer-Podcast

Podcast by Carl-Philip Hänsch

Publisher

Carl-Philip Hänsch

Category

technology

Language

de

Explicit

No

First episode

2 Jan 2021

Latest episode

6 Aug 2021

Latest episodes

13 episodes in the feed.

1. 

   6 Aug 2021

   Folge 11 – Das CRUD - Pattern

   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.

2. 

   22 Feb 2021

   Folge 10 - Technische Schulden

   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.

3. 

   15 Feb 2021

   Folge 9 - Kompression Von Quellcode

   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.

4. 

   10 Feb 2021

   Folge 8 - Programmierung Eines Eigenen Git - Hosting - Tools

   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.

5. 

   1 Feb 2021

   Folge 7: Code neu schreiben, Projekte weiterpflegen

   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.

6. 

   27 Jan 2021

   Folge 6: 100-fache Performance durch LEFT-JOIN-Trick bei SQL

   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.

7. 

   25 Jan 2021

   Folge 5 - Performance Vs Abstraktion

   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.

8. 

   11 Jan 2021

   Folge 4 – Kurzer Code Ist Schön

   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.

9. 

   7 Jan 2021

   ERPL Vorstellung

   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.

10. 

    3 Jan 2021

    Folge 3: Software Composition

    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.

11. 

    2 Jan 2021

    Folge 2: Separation of Concerns implementieren mit dem „Hook Registry“ Design Pattern

    In der letzten Folge habe ich das Thema Separation of Concerns angesprochen. Das Ziel dahinter ist, den Code eines Projekts so weit voneinander zu trennen, dass man den Aufwand deutlich reduziert, wenn Änderungen am Code zu machen sind, oder Sachen wieder rausfliegen oder ersetzt werden sollen. Dazu soll jeweils der Code, der zu einem Concern - oder auch Feature genannt – gehört, möglichst beisammen bleiben und nicht mit anderem Code, der andere Features umsetzt, gemischt werden. Eine relativ einfache Methode möchte ich euch heute vorstellen, da sie von vielen Plugin-Systemen wie z.B. der Eclipse IDE, aber auch allen gängigen Browsern in ihren Plugin-Systemen verwendet werden. Ihr könnt euch also eine „sauber programmierte Software“ wie ein leeres Programm vorstellen, bei dem jedes Feature wie durch ein Plugin jederzeit hinzufügbar – oder entfernbar ist. Die Rede ist von der Hook-Registry. Dabei handelt es sich um ein zentrales Register an Hooks, also Callbacks, die zu einem bestimmten Zeitpunkt zu einem bestimmten Zweck aufgerufen werden. Um es etwas plastischer zu machen, nehme ich das Menüsystem zum Beispiel. Angenommen, die Software hat ein Hauptmenü mit den Menüpunkten Datei, Bearbeiten, Ansicht, Fenster und Hilfe mit ihren jeweiligen Unterpunkten: Datei Neu Öffnen Schließen Beenden. In schlecht organisierter Software gibt es jetzt einen zentralen Punkt, wo die Menüs aufgebaut werden: Die Liste mit Menüeinträgen muss vollständig sein und verweist auf Funktionen quer durch die Software. Anschließend sind die Aktionen hinter den Menüeinträgen in den einzelnen Dateien ausimplementiert. Warum ist das schlecht? Naja jedes mal, wenn jemand ein neues Feature hinzufügen will oder entfernen muss, muss er nicht nur die Dateien anfassen, die das eigentliche Feature implementieren, sondern zusätzlich noch eine handvoll zentraler Dateien (wie der Menü-Aufbau-Code oder eine Initialisierungs-Routine oder eine große If-Kaskade, in der nochmals alle vorhandenen Features aufgelistet sind), anfassen. Vergisst man eine dieser Stellen, macht man die Software kaputt oder hinterlässt funktionslose Menüpunkte.

12. 

    2 Jan 2021

    Saubere Programmierung – was ist „schöner Code“? Folge 1: Separation of Concerns

    Saubere Programmierung – was ist „schöner Code“? Folge 1: Separation of Concerns Die meisten Entwickler lernen Programmieren durch ihren Spieltrieb – sie setzen sich das Ziel, eines Tages Spiele programmieren zu können oder wollen ein eigenes Web-Portal betreiben, vielleicht das nächste Facebook aufbauen. In dieser Phase geht es einfach nur darum, Sachen zum Laufen zu bekommen. Es wird Code rauskopiert, neu zusammengesetzt, getestet – bis alles funktioniert. Ich will euch heute eine neue Sichtweise auf Code beibringen, die über das reine „Funktionieren“ hinausgeht. Quasi um „schönen Code“ Ein paar Basics wird bestimmt jeder mal gehört haben: Variablen aussagekräftig benennen, Funktionsnamen sinnvoll wählen. Ich will euch aber einen weiteren Aspekt beibringen, der dich in deinem Programmiererleben viel Nacharbeit ersparen wird: Die Rede ist vom „Separation of Concerns“. Ein Concern, englisch, bedeutet „Anliegen“. Ein Anliegen ist zum Beispiel: „ich will mich einloggen können“ – ein anderes Anliegen ist „ich will eine Bestellung erfassen können“ – ein anderes „die Bestellungen sollen mit dem Lagerprogramm synchronisiert werden“ In der Uni lernt ihr eine Denkweise des Separation of Concern: Die MVC oder Model View Controller Sichtweise. Die besagt, dass ihr den Code für das Datenschema, die UI-Darstellung, sowie das Verhalten eurer Objekte code-technisch auf mehrere Dateien aufteilen sollt. Das Ziel hinter MVC ist sicherlich ein ehrbares. Aber die Stelle, an der hier der Querschnitt gemacht wird, gefällt mir nicht. Ich kann euch das an einem einfachen Beispiel zeigen: Ihr habt mehrere Concerns, ein Concern ist dass ihr die Adresse im Kunden speichern wollt für den Postversand. Ein anderer Concern ist, dass ihr die Bankverbindung speichern müsst, um die SEPA-Lastschrift durchführen zu können. Unterteilt man die Software jetzt Objektorientiert nach MVC, schmeißt man beide Concerns 1. ins selbe Objekt und 2. auch gemeinsam in die View-Datei. Die Folge: Will der Kunde jetzt das SEPA-Lastschrift-Feature doch nicht mehr, müsst ihr anfangen, die Dateien zu zerpflücken. Das führt zu Fehlern, blinde Felder, toter Code usw. - Hätte man die Concern-Grenzen besser gesetzt, hätte man nur eine Datei löschen müssen und das SEPA-Feature wäre sauber aus der Software wieder herausgeschnitten. Die genauen Techniken, wie man diese scharfe Trennung der Concerns erreicht, kommt aus dem Bereich Aspect Oriented Programming und Feature Oriented Programming. Ich werde die Techniken in dieser Folge nicht erklären – dazu wird es noch viele Folgen geben. Ich will euch nur zeigen, dass das Thema sauberer Code komplex ist und du noch viele Verbesserungen an deinem Code erlernen kannst. Wenn dich das Thema interessiert, dann abonniere diesen Podcast und höre dir die anderen Folgen noch an.

13. 

    2 Jan 2021

    Firmenvorstellung - Launix und FOP

    Eine grobe Firmenvorstellung von Launix und FOP (https://launix.de/launix/) Ich will euch ein bisschen mitnehmen, was Launix ist, was unsere Ziele sind. Als wir 2012 angefangen haben, gab es auf dem Software-Markt nur 2 Extreme: Günstige Standard-Software nach dem Motto „friss oder stirb“ oder Individualprogrammierung, bei der man ein paar 10.000- oder 100.000€ in ein Projekt gesteckt hat. Wir waren eine Firma auf dem Individual-Markt. Doch das Problem: Obwohl so eine individuelle Software jeder haben wollte, war unsere Herstellungsmethode für Software zu teuer für den Klein- und Mittelstand. Die Folge: Entweder kostendeckende Preise und keine Aufträge – oder Dumping-Preise und wir finden keine Programmierer für das Gehalt. Dann haben wir festgestellt, dass sich die meiste Programmierung für Business-Software immer wieder wiederholt: Kundenliste, Rechnungen, Angebote, Passwort-Login. Also haben wir angefangen, aus jedem Feature ein eigenes „Produkt“ zu machen, das wir mehrmals verkaufen könnten – vorausgesetzt es gäbe eine Möglichkeit – eine Programmiersprache – mit der man die Features wieder zu einer individuellen Software zusammensetzen kann. Und genau das leistet FOP – Feature Oriented Programming. Und jetzt sind wir in der Lage, individuelle Software zum selben Preis wie „normale“ Software zu liefern. Besser noch: Durch die Feine Einteilung von Features können wir den Grad zwischen günstigem Preis und Individualität beliebig fein einstellen. Wir möchten Sie auf dem Weg zur Digitalisierung begleiten. Sie starten mit dem Standard-ERPL und mit weiterem Wachstum kommen unsere branchenspezifischen Spezial-Module hinzu. Außerdem bieten wir die Anbindungsprogrammierung an alle möglichen Schnittstellen, Webseiten und Shops an. Somit müssen Sie Ihr System nicht mehr mit jedem Wachstumsschritt wechseln, sondern bleiben bei einem einzigen Anbieter. Melden Sie sich noch heute bei uns und profitieren Sie von unserer Digitalisierungs-Erfahrung.

Contact Pro-Grammierer-Podcast

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.