Pro-Grammierer-Podcast

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.

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.

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.