Codelution Blog

Die 6 Säulen erfolgreicher Softwareprojekte

2021-05-13T00:00:00Z

Bei Softwareprojekten gibt es eine Reihe wiederkehrender Faktoren, die den Unterschied zwischen einem erfolgreichen Abschluss und einem Fass ohne Boden machen. Besonders bei den inzwischen oft eingesetzten agilen Vorgehensmodellen gibt es eine Reihe von Aspekten und Zusammenhängen, die es unbedingt zu beachten gilt.

In der Softwareentwicklung kommen die verschiedensten Vorgehensmodelle zum Einsatz. Dabei kann ganz grob zwischen klassischen Modellen (wie z.B. dem Wasserfallmodell) oder iterativen Modellen (z.B. Scrum) unterschieden werden. Egal welches Modell eingesetzt wird, es kommen immer wieder die gleichen Projektphasen zum Einsatz. Die Vorgehensmodelle unterscheiden sich primär in der Reihenfolge und der Art und Weise wie sie durchlaufen werden.

Die Projektphasen

In klassischen Modellen, werden die Projektphasen der Reihe nach abgearbeitet. Bei iterativen Modellen wiederholen sich bestimmte Projektphasen, um besser auf sich ändernde oder unklare Anforderungen eingehen zu können.

Die Projektphasen sind:

Planungsphase (u.a. Anforderungsanalyse)
Definitionsphase (Entwurf)
Implementierungsphase (Umsetzung)
Test
Inbetriebnahme (auch Veröffentlichung)
Instandhaltung

Auf Fehlersuche

Wenn Probleme im Softwareprojekt auftauchen, sollte die erste Frage immer sein: woher, aus welcher Phase, kommen die Probleme? In der Praxis offenbart sich bei der Suche nach der Ursache dann oft, dass mehrere Phasen nicht richtig durchgeführt wurden bzw. der gesamte Entwicklungsprozess an sich große Mängel aufweist.

Ein typischer, und sehr schnell fataler, Fehler liegt in der ungenügenden Durchführung der Entwurfsphase. Gerade wenn ein erfahrener Softwarearchitekt fehlt, neigen Teams zu sogenannten Brain-To-Code. Dabei wird die Konzeptphase mehr oder weniger übersprungen und es wird direkt "gehackt". Es wird schnell Programmcode geschrieben und zunächst auch "Working Software" erzeugt. Aufgrund des fehlenden Softwaredesigns ergeben sich jedoch mittelfristig unerwünschte Abhängigkeiten im Programm und es treten Fehler auf. Durch diese Abhängigkeiten führen Bugfixes an der einen Stelle dann unbewusst zu Beschädigungen an anderer Stelle. Die Produktivität sinkt. Die typischen Symptome zeigen sich dann in der Regel nach einem Invest von 9-18 "Entwickler Mannmonaten".

Agil bedeutet nicht ungeplant.

Bei iterativen Vorgehensmodellen wird zumeist versucht "agil" zu sein.

Agil bedeutet in diesem Zusammenhang, dass man "flink" auf geänderte Anforderungen reagieren kann. Anstatt zu Projektbeginn eine umfassend detaillierte Planung durchzuführen, werden die oben genannten Phasen für jedes Feature immer wieder erneut durchlaufen.

In agilen Prozessen muss daher beispielsweise die Planungsphase als fester Termin im Sprint eingeplant sein - das ist bei Ihnen sicherlich der Fall, oder?

Wir wollen ja nicht nach Brain-To-Code arbeiten sondern unsere Software ingenieursmäßig konzipieren.

Beispiel Scrum

Das verbreiteste agile Vorgehensmodell im Bereich der Softwareentwicklung ist sicherlich Scrum. Wo finden wir die o.g. Phasen in Scrum? Und was sollte man dabei beachten?

1. Anforderungsanalyse - für mehrere Sprints im Voraus

Die Anforderungsanalyse sollte vor jedem Sprint stattgefunden haben. In größeren Projekten kann damit sogar ein eigenes Team beauftragt werden. Es sollte sichergestellt werden, dass die Anforderungen für mehrere Sprints im Voraus definiert werden. So stabil sollten die Anforderungen schon sein. Sonst laufen Sie Gefahr, immer wieder Funktionalitäten aufgrund neuer Erkenntnisse ändern zu müssen. Die Anforderungen fließen dann in Form von User Stories ins Backlog ein.

2. Planungsphase - Verbindliche Termine

Die Planungsphase muss vor Umsetzungsbeginn und damit direkt am Anfang des Sprints stattfinden. Verbindliche Termine schaffen Struktur und sorgen für eine nachhaltige Produktqualität. Das Softwaredesign sollte vom Team gemeinsam entwickelt werden - auch wenn die Umsetzung danach durch einzelne Entwickler stattfindet. Dadurch verteilen Sie das Wissen im Team und holen auch schwächere Teammitglieder ab.

3. Umsetzung - neueste Technik verwenden

Der Großteil des Sprints konzentriert sich auf die Umsetzung. Die Umsetzung sollte nach neuestem Stand der Wissenschaft und Technik erfolgen. Zu diesem Punkt gehört nicht nur die Entwicklung von Funktionalitäten, sondern auch von UI-Entwürfen oder Erweiterungen für Dev-Ops.

4. Tests - Keep it going

Tests können und sollten fortlaufend durchgeführt werden. Verwenden Sie verschiedene Testverfahren. Unit-Tests, UI-Tests, Integrationstests, ... Vor der Sprint-Demo mit den Stakeholdern sollte das Team alle umgesetzten Funktionalitäten noch einmal gemeinsam durchtesten.

5. Inbetriebnahme - Demo mit den Stakeholdern

Natürlich gibt es auch dedizierte Inbetriebnahmen. Dennoch sollten Sie auch während der Sprints immer eine Inbetriebnahme durchführen: und zwar vor der Demo. Deployen Sie Ihre Anwendung beispielsweise auf einen speziell dafür eingerichteten Demo-Server - dieser sollte den Stakeholdern auch nach der Demo zur Verfügung gestellt werden. Wir sagen deswegen: auch die Inbetriebnahme findet sich bei Scrum - in Form der Demo mit den Stakeholdern.

6. Instandhaltung - Retrospektive für fortlaufende Verbesserung

Nach Abschluss eines (agilen) Projekts können sich Instandhaltungs- oder Betreuungsaufgaben ergeben. Diese lassen sich auch gut mittels KANBAN managen. Ansonsten nutzen Sie bei Scrum die Retrospektive, um Ihren Entwicklungsprozess "in Stand zu halten" und fortlaufend zu verbessern.

Sie haben weiterführende Fragen oder stehen vor Herausforderungen in Ihrem eigenen Entwicklungsprozess? Sprechen Sie uns gerne an. Wir freuen uns über Ihre Nachricht.

Vorsicht wenn Entwickler den Begriff Refactoring verwenden

2021-05-22T00:00:00Z

Kennen Sie das, Sie besprechen neue Anforderungen und dann sagt ein Entwickler: „das müssen wir refactorn‘“? Was genau ist Refactoring und warum sollten alle stutzig werden wenn dieser Begriff fällt?

Refactoring ist ein bekannter Begriff in der Softwareentwicklung und wurde vor Martin Fowler in dessen Buch „Refactoring – Improving the Design of existing Code“ geprägt. Wie der Titel impliziert, zielt Refactoring darauf ab, die Struktur und das Design von Programmcode zu verbessern, ohne dabei die Funktionalität des Codes (also sein externes Verhalten) zu verändern. Refactoring ist quasi eine Art interne Modifizierung.

Als das Buch erschien, entstand zu Recht ein großer Hype, da die Ansätze neu und auch gut waren. Fowler beschreibt in seinem Buch verschiedene „Code-Smells“, das sind Merkmale an denen man schlechten Code erkennen kann. Gleichzeitig werden Refactorings vorgeschlagen, also Änderungsschritte, um von schlechtem Code zu besserem, wartbarem Code zu kommen. Das Buch enthält viele „Musterrefactorings“, quasi Rezepte, wie Programmcode ‚einfach‘ von A nach B gewandelt werden kann.

Erst kommt der Fehler, dann das Refactoring

Wenn bei Ihnen Refactoring ein Thema ist, wurden im Voraus schon Fehler gemacht. Es liegen Qualitätsprobleme vor und die Erweiterungsfähigkeit der Software muss erst wiederhergestellt werden.

Kleine Teilaspekte einer Software können leicht "gerefactored" werden. Oft ist es aber so, dass im Rahmen eines "sog. Refactorings" an verschiedensten Stellen Änderungen vorgenommen werden müssen oder sogar die Domänenlogik schlecht oder falsch abgebildet ist. Aus einem mikroskopischen Refactoring ergeben sich mehrere Änderungen an verschiedensten Stellen im Programm. Dabei handelt es sich bereits um ein (partielles) "Redesign". Wenn dieses dann auch noch das System an anderer Stelle beschädigt können Sie einpacken.

In vielen Unternehmen wird Refactoring stillschweigend akzeptiert.

Unser Ansatz ist aber: wir sollten es gleich richtig machen!

Software sollte so umgesetzt werden, dass Refactoring erst gar nicht notwendig ist. Kommt es zu Problemen, hat zu Beginn ein stimmiges Softwaredesign in der Konzeptionsphase gefehlt. Software muss von Beginn an nachhaltig und erweiterbar sein. Ein wohlüberlegtes Softwaredesign ist notwendig und reduziert Folgekosten, die bei Änderungsschritten anfallen, um die Wartbarkeit wieder herzustellen.

Kein Widerspruch zu YAGNI

Ein erweiterbares Softwaredesign gibt es nicht für umsonst. Dennoch verstößt es nicht gegen das Clean Code Prinzip YAGNI (You ain’t gonna need it). YAGNI bezieht sich auf die Umsetzung von unnötigen Funktionalitäten. Die konzeptionellen Arbeiten die für ein sauberes Softwaredesign notwendig sind, sind nie unnötig sondern Voraussetzung für eine nachhaltige Produktentwicklung.

Ganzheitlicher Clean-Code Ansatz als Lösung

Wie erreichen wir nachhaltige, erweiterbare Software? Leider gibt es hier keinen magischen Schalter, nach dessen Betätigung alles reibungslos funktioniert. Angefangen beim Entwicklungsprozess, über die richtigen Technologien, bis hin zu den individuellen Codingskills der Teammitglieder, müssen eine Vielzahl von Aspekten berücksichtigt werden. Die Praktiken aus der Clean-Code Initiative (wie z.B. die SOLID Prinzipien) dienen als wichtiger Start. Moderne Clean-Code Ansätze betrachten die Softwareentwicklung deswegen immer ganzheitlich und beziehen auch immer angrenzende Aspekte der Entwicklung mit ein.

Fazit

Refactoring ist ein häufig verwendeter Begriff ist, den nicht nur Entwickler, sondern auch viele Abteilungsleiter und Personen in Managementfunktionen immer wieder hören werden. Die wichtigste Erkenntnis ist: Wenn Software immer wieder gerefactored werden muss, dann liegen Qualitätsprobleme vor. Massive Folgekosten sind die Konsequenz. Refactoring kann durch ganzheitliche Maßnahmen im Voraus verhindert werden.

IOSP: das vielleicht unbekannteste Clean Code Prinzip

2021-06-17T00:00:00Z

Viele Clean Code Prinzipien (wie z.B. DRY, KISS, YAGNI) sind weit verbreitet und den meisten Entwicklern bekannt. Diese Prinzipien sind intuitiv und schnell zu verstehen. Überraschenderweise ist eines der mächtigsten und wirkungsvollsten Clean Code Prinzipien aber relativ unbekannt. Es handelt sich um das IOSP. Das sogenannte Integration Operation Segregation Principle. Dieses Prinzip wird die Art und Weise wie Sie Software entwerfen entscheidend verändern.

Herausforderung

Verständlicher und leicht zu wartender Quellcode ist der Traum eines jeden Softwareentwicklers. Zu Beginn der Umsetzung ist das auch meist der Fall. Unser Programmcode ist noch übersichtlich und leicht zu verstehen:

Mit zunehmender Zeit, mutiert Programmcode jedoch immer weiter zu Spaghetti-Code. Schon nach kurzer Zeit sieht der oben gezeigte Code dann so aus:

Warum ist das so? Der Grund dafür ist, dass die primäre Intention des Codes, durch (notwendige) Sekundäraspekte verschmutzt wird. Sekundäraspekte sind Aspekte wie Validierung, Logging, Asynchronität, Fehlerbehandlung usw. Kurz gesagt alle Aspekte, die nicht primär der Erfüllung unserer Business-Anforderungen, dienen.

Das sogenannte Integration Operation Segregation Principle ist eines der Schlüsselprinzipien mit dessen Hilfe wir zu verständlichem Programmcode zurückkehren können. Dieses Prinzip wird die Art und Weise wie Sie Software entwerfen entscheidend verändern!

Erklärung des IOSP

Definition

Das Integration Operation Segregation Principle, zielt darauf ab den Programmcode in Integrationsslogik (Integration) und Operationslogik (Operation) aufzutrennen (engl. segregate).

Unter Operationslogik verstehen wir den Teil unserer Geschäftslogik, der das „wie“ im Detail beschreibt. Dabei kommen alle bekannten Kontrollstrukturen (if, else, …), Operatoren oder Datentypen usw. zum Einsatz.

Die Integrationslogik ist der Teil unserer Anwendung, der keine eigene „Berechnungslogik“ enthält, sondern nur noch Operationslogik (oder andere Integrationslogik) aufruft, also nur aus Funktionsaufrufen besteht.

Beispiel

Schauen wir uns das IOSP anhand eines einfachen Hello World Beispiels an. Die Besonderheit in unserem Beispiel ist, wir wollen in Abhängigkeit eines Konfigurationsschalters den Text Hello World in Großbuchstaben oder in Kleinbuchstaben ausgeben.

class Program
{
    static void Main(string[] args)
    {
        var textErzeugen = new TextErzeugen(new TextGrossSchreiben(), new ConfigService());

        Console.WriteLine(textErzeugen.Erzeugen());

        Console.ReadLine();
    }
}

public class TextErzeugen : ITextErzeugen
{
    private readonly ITextGrossSchreiben _textGrossSchreiben;
    private readonly IConfigService _configService;
    private const string Text = "Hello World";

    public TextErzeugen(ITextGrossSchreiben textGrossSchreiben, IConfigService configService) 
    {
        _textGrossSchreiben = textGrossSchreiben;
        _configService = configService;
    }

    public string Erzeugen()
    {
        if (_configService.SollTextGrossGeschriebenWerden)
            return _textGrossSchreiben.GrossSchreiben(Text);

        return Text;
    }
}

public class TextGrossSchreiben : ITextGrossSchreiben
{
    public string GrossSchreiben(string text)
    {
        return text.ToUpper();
    }
}

Natürlich könnte dieses einfache Beispiel auch komplette in einer Methode implementiert sein. Für Lernzwecke ist aber bereits eine gewisse Modularisierung vorgesehen. Aktuell gibt es noch keine Unterscheidung zwischen Integrationslogik und Operationslogik. So wird beispielsweise in der Klasse TextErzeugen der Config Service aufgerufen (Integrationslogik). Gleichzeitig liegt durch das if Statement aber auch Operationslogik vor. Ähnlich verhält es sich mit der Main Methode. Der Aufruf von textErzeugen.Erzeugen() ist Integrationslogik. Das Ausgeben auf der Konsole ist hingegen Operationslogik.

Wir gehen einen Schritt weiter und werfen einen Blick auf die Unit-Tests der Klasse TextErzeugen:

[TestClass]
public class TextErzeugenTests
{
    private ITextErzeugen _target;
    private IConfigService _configService;

    [TestInitialize]
    public void SetUp()
    {
        var textGrossSchreiben = MockRepository.GenerateStub<ITextGrossSchreiben>();
        _configService = MockRepository.GenerateStub<IConfigService>();

        textGrossSchreiben.Stub(x => x.GrossSchreiben("Hello World")).IgnoreArguments().Return("HELLO WORLD");

        _target = new TextErzeugen(textGrossSchreiben, _configService);
    }

    [TestMethod]
    public void Erzeugen_GrossSchreibenAktiviert_ErzeugtHelloWorldTextGroß()
    {
        _configService.Stub(c => c.SollTextGrossGeschriebenWerden).Return(true);

        var result = _target.Erzeugen();

        Assert.AreEqual("HELLO WORLD", result);
    }

    [TestMethod]
    public void Erzeugen_GrossSchreibenDeaktiviert_ErzeugtHelloWorldTextKlein()
    {
        _configService.Stub(c => c.SollTextGrossGeschriebenWerden).Return(false);

        var result = _target.Erzeugen();

        Assert.AreEqual("Hello World", result);
    }
}

In den Unit-Tests, wird (in Abhängigkeit des Konfigurationsschalters) geprüft, ob der Text groß oder klein geschrieben werden soll. Bedenken Sie aber, dass wir eigentlich das Erzeugen von Text testen möchten. Stattdessen testen wir, dass die Funktion das Ergebnis liefert, welches wir im Stub selbst vorgegeben haben – was wird hier also überhaupt getestet? Es handelt sich schon gar nicht mehr um einen einfachen Unit-Test, sondern vielmehr um einen Integrationstest. Die Abhängigkeiten unserer zu testenden Klasse sind ein Problem. Mit weiteren Abhängigkeiten wird der Test noch komplexer. Endlose Mocking und Stubbing Orgien sind die Konsequenz. Wenn wir die Topologie unseres Programms bzw. dessen Programmteile betrachten, fällt schnell auf, dass Integrationslogik und Operationslogik vermischt sind:

Lösung

Die Lösung unserer o.g. Probleme liegt in der konsequenten Anwendung des IOSP. Wir trennen strikt zwischen Integrationslogik und Operationslogik und erhalten folgende Programmtopologie:

Es ist deutlich zu sehen, dass sich die Operationslogik (das „WIE“) immer in den Blättern des „Programmtopologiebaumes“ befindet. Diese Operationslogik ist durch Anwendung des IOSP nun sehr klar und erfüllt ausschließlich den im Namen der Klasse / Funktion definierten Zweck:

public class TextErzeugen : ITextErzeugen
{
    public string Erzeugen()
    {
        return "Hallo Welt!";
    }
}

public class ConfigService : IConfigService
{
    public bool SollTextGrossGeschriebenWerden()
    {
        return true;
    }
}

public class TextGrossSchreiben : ITextGrossSchreiben
{
    public string GrossSchreiben(string text, bool grossSchreiben)
    {
        return grossSchreiben ? text.ToUpper() : text;
    }
}

Da die Abhängigkeiten verschwunden sind, lassen sich die „Operationsfunktionen“ auch ganz einfach Unit-Testen.

Die Klarheit der Funktionen mit Operationen hat im Vergleich zum letzten Beispiel deutlich zugenommen. Das trifft auch auf die Klassen mit reiner Integrationslogik zu, wie z.B. der HelloWorld Klasse:

public class HelloWorld : IHelloWorld
{
    private readonly ITextErzeugen _textErzeugen;
    private readonly IConfigService _configService;
    private readonly ITextGrossSchreiben _textGrossSchreiben;
    private readonly ITextAusgeben _textAusgeben;

    public HelloWorld(
        ITextErzeugen textErzeugen,
        IConfigService configService,
        ITextGrossSchreiben textGrossSchreiben,
        ITextAusgeben textAusgeben)
    {
        _textErzeugen = textErzeugen;
        _configService = configService;
        _textGrossSchreiben = textGrossSchreiben;
        _textAusgeben = textAusgeben;
    }

    public void SayHello()
    {
        var text = _textErzeugen.Erzeugen();
        var grossSchreiben = _configService.SollTextGrossGeschriebenWerden();
        var grosserText = _textGrossSchreiben.GrossSchreiben(text, grossSchreiben);

        _textAusgeben.Ausgeben(großerText);
    }
}

Vergleichen Sie jetzt noch einmal die erste Version des vermeintlich einfachen HelloWorld Beispiels mit dieser optimierten Version! Wunderschön. Das Programm – besonders die SayHello Methode – ist deutlich einfacher und verständlicher. Sie besteht aus reinen Funktionsaufrufen. Wir können diese Funktion von oben nach unten „lesen“ und verstehen, ohne Code zu „interpretieren“.

Fazit

Das IOSP trennt die Intention (WAS wollen wir tun) von der tatsächlichen Ausführung (WIE wollen wir es tun). Das führt zu lesbarem und verständlichem Programmcode. Das IOSP ist eines der Schlüsselprinzipien um Spaghetti-Code zu vermeiden. Und ja, auch Sie können das! Das IOSP bietet noch viel mehr Vorteile, die den Rahmen des Blogartikels sprengen würden.

Unser Beispiel war einfach, dennoch können Sie das IOSP in jedem Programm und auf eine Vielzahl von Problemen anwenden! Die Umsetzung erfordert allerdings Übung. Beim Design von Software gibt Vorgehensmuster, um IOSP-kompatiblen Code zu erhalten. Sie sollten sich dabei von einem erfahrenen Coach begleiten lassen.

Wie funktioniert die Zusammenarbeit mit einem Softwaredienstleister?

2021-07-15T00:00:00Z

Sie ziehen die Zusammenarbeit mit einem Softwaredienstleister in Betracht oder haben sich bereits dafür entschieden? Im folgenden Artikel erklären wir, wie die Zusammenarbeit mit einem SW-Dienstleister prinzipiell abläuft, worauf Sie achten sollten und wie Sie auch bei vielen parallel laufenden Projekten den Überblick behalten.

Sie ziehen die Zusammenarbeit mit einer Softwareagentur in Betracht oder haben sich bereits dafür entschieden? Im diesem Artikel erklären wir, wie die Zusammenarbeit mit einem SW-Dienstleister prinzipiell abläuft, worauf Sie achten sollten und wie Sie auch bei vielen parallel laufenden Projekten den Überblick behalten.

Kennenlernen

Aller guter Anfang startet mit einem unverbindlichen Erstkontakt. Möglicherweise hatten Sie in der Vergangenheit bereits Kontakt mit einem Dienstleister?

Unser Tipp ist: ziehen Sie auf jeden Fall auch kleinere Partner (< 10 Mitarbeiter) in Betracht. Von diesen erhalten Sie oftmals bessere Services als von großen Agenturen, bei denen Sie nach Schema F behandelt werden.

Im optimalen Fall arbeiten Sie sogar mit mehr als nur einem Dienstleister zusammen. Wie auch beim Aktien Portfolio oder bei der Verteilung von Know-How auf ihre internen Mitarbeiter ist Diversifizierung langfristig unerlässlich.

Beratungsgespräch

Nach dem ersten positiven Eindruck findet im zweiten Schritt ein Vorgespräch statt. Hier tauschen Sie sich über den genauen Bedarf an Unterstützung aus. Zudem wird beraten, welches das passende Projektmodell für eine mögliche Zusammenarbeit ist. Unterschieden wird zwischen dem klassischen Werkvertrag mit Fixpreis, und Dienstleistungsverträgen auf Stundensatzbasis.

Werkverträge kommen in Frage, wenn das zu liefernde Werkstück (die Software) klar definiert werden kann und Sie aus Planungsgründen einen fixen Preis bevorzugen.
Dienstleistungsverträge kommen in Frage, wenn die Anforderungen nicht ganz klar sind, oder Sie auch nach Beauftragung das Projekt beeinflussen bzw. steuern möchten.

Dienstleistungs- oder Werkverträge treffen keine Auskunft darüber, wo die Leistung erbracht wird. Allerdings ist es bei Dienstleistungsverträgen etwas üblicher, dass die Leistungserbringung direkt in Ihrem Unternehmen stattfindet (z.B: Beraterverträge, flexible Projekt-Unterstützung für Ihr Team usw.). Es sind aber auch Mischformen denkbar.

Der Dienstleister muss zu diesem Zeitpunkt schon eine kleine Bedarfsanalyse durchführen. Möglicherweise werden bereits zu diesem Zeitpunkt Betriebsgeheimnisse ausgetauscht.

Unser Tipp: Ein seriöser Dienstleister sollte Sie bereits zu diesem Zeitpunkt auf den Abschluss einer Geheimhaltungserklärung hinweisen.

Anforderungsermittlung

Im nächsten Schritt werden die Projektanforderungen konkret bestimmt. Bei Werkverträgen werden alle umzusetzenden Funktionalitäten definiert. Auch bei agilen Projekten, die meist mittels Dienstleistungsverträgen durchgeführt werden, muss Konsens über die Produktvision und die Grundmenge an Anforderungen geschaffen werden. "Agil" bedeutet nicht ungeplant, sondern dass Sie während des Projekts flexibel die Anforderungen ändern können.

Der Dienstleister sollte von sich aus eine Übersicht über die benötigten Skills und Tätigkeiten erstellen. Je nach Aufwand, muss die Anforderungsermittlung extra vergütet werden. Dafür sollten Sie dann auch ein Ergebnis erhalten, das Sie auch an andere Dienstleister (zur Erstellung von Alternativangeboten) verwenden können, zum Beispiel in Form eines Lasten- bzw. Pflichtenhefts, Visionsdokuments, o.ä..

Unser Tipp: Wenn die Anforderungsermittlung bepreist wird, können Sie das Ergebnis zur Angebotserstellung durch alternative Dienstleister verwenden.

Angebot

Die Ergebnisse der Anforderungsermittlung münden dann in einem qualifizierten Angebot. Je nach Umfang der Anforderungen und Projektmodell sollte das Angebot auch Spezifikationen umfassen, z.B. in Form eines Pflichtenhefts. Achten Sie beim Angebot auf:

WAS: Welches "Werkstück" liefert Ihr Partner genau, welche Dienstleistungen erbringt er im Detail?
WANN werden welche Ergebnisse bzw. Dienstleistungen geliefert?
WIE: In welcher Form erfolgt die Übergabe von Programmcode, UI-Entwürfen und Dokumentation? Gibt es Adobe XD Klickprototypen für UI-Entwürfe? Folgt die Dokumentation einem branchenüblichen Standard, wie z.B. Arc42?
WO erfolgt die Erbringung der Leistung?
WIE LANGE ist das Angebot gültig? Wie lange "reserviert" der Anbieter seine Ressourcen?
ABNAHME: welches Mitspracherecht haben Sie bei der Abnahme der beauftragten Leistungen und aufgrund welcher Kriterien erfolgt die Abnahme? Natürlich wünschen Sie sich viel Kontrolle bei der Abnahme. Bedenken Sie aber: Abnahmeprozesse sind auch für Ihr Unternehmen aufwändig. Für formale Abnahmen sollte eine Frist definiert werden (z.B. zwei Wochen), nach deren Ablauf die gelieferten Leistungen automatisch als abgenommen gelten.
ZAHLUNG: Bei Werkverträgen sind Anzahlungen, Abschlagszahlungen und eine Schlusszahlung üblich. Es muss ersichtlich sein, was Sie in welcher Form für welche Zahlung erhalten.

Für externe Ressourcen (Dienstleister) gilt das selbe wie für interne Ressourcen (Ihre Mitarbeiter). Sie müssen sicherstellen, dass Ihr Business auch nach Ausfall einer Ressource funktionsfähig bleibt. Gerade für größere Projekte gilt deswegen:

Unser Tipp: ein professioneller Dienstleister wird nicht versuchen sich unentbehrlich zu machen, sondern seinen Wert durch das Anbieten einer Übergabephase und Integrationsphase zu beweisen.

Beauftragung

Nach eingehender Prüfung des Angebots erfolgt dann die Beauftragung des Dienstleisters und die Zusammenarbeit kann beginnen.

Reporting

Unser Tipp: Um den Überblick über extern beauftragte Projekte zu behalten ist ein leistungsfähiges Reporting unerlässlich. Das Reporting sollte alle relevanten Informationen enthalten und einfach zu verstehen sein.

Bei Codelution verwenden wir ein Online-Kundenportal und kommunizieren regelmäßig die folgenden Informationen:

Was genau wurde beauftragt? In unserem Kundenportal legen wir alle Beauftragungen und Verträge ab. In der Projektübersicht können unsere Kunden alle Verträge und Unterpositionen samt Status einsehen.

Wie laufen die Beauftragungen? Neben regelmäßigen Gesprächen setzen wir auf monatliche Projektberichte in Form von verbindlichen schriftlichen Dokumenten. In diesen kommunizieren wir den Projektstatus. Kurz. Aussagekräftig. Ohne technische Details.
Wann enden die Projekte? Ein Gantt-Chart eignet sich optimal, um bei einer Vielzahl von Projekten den Überblick zu behalten (oft gibt es auch noch Abhängigkeiten zwischen den Projekten). Auch bei agilen Projekten, hilft ein Releaseplan in Form eines Ganttdiagramms ungemein.

Fazit

Ein erfolgreiches Projekt startet mit einer professionellen Projektanbahnung, bei der bestimmt wird, ob eine Zusammenarbeit für beide Seiten Sinn ergibt, eine klare Bestimmung des Status-Quo und einer möglichst exakten Festlegung des Zieles und der zu erbringenden Leistungen. Auch bei agilen Projekten sollte eine Grundmenge der anfänglichen Anforderungen klar sein. Während der Zusammenarbeit stellt ein professionelles Reporting sicher, dass Sie immer den Überblick behalten und maximale Transparenz geschaffen wird. Wenn dies alles gewährleistet wird, dann haben Sie die besten Voraussetzungen dafür, dass Ihr Projekt zu einem vollen Erfolg wird.

Test Driven Development: Wahrscheinlich machen Sie's falsch

2021-10-17T00:00:00Z

Test Driven Development (TDD) ist eine Methodik bei der Entwicklung von (Unit-) Tests. Dieser Artikel diskutiert die Vor- und Nachteile der testgetriebenen Entwicklung und wann TDD zum Irrweg wird.

TDD ist eine aus XP (eXtreme Programming) bekannte Methodik, bei der die Unittests vor der eigentlichen Implementierung kodiert werden. Basierend auf den Anforderungen an das Programm werden in kurzen Iterationen Tests und erst nach einem Test die entsprechende Lösung entwickelt. Da es bei bzw. direkt nach der Entwicklung des Tests noch keine Implementierung gibt, gegen die der Test ausgeführt werden kann, schlägt jeder Test zunächst fehl. Man sagt auch, der Test ist rot. Im nächsten Schritt wird die Implementierung für den Test geschrieben. Der Test wird dadurch grün. Danach kann die Implementierung refaktoriert werden (blau). Der TDD Zyklus ist also:

Oder auch:

Vorteile

Die testgetriebene Entwicklung kann Vorteile bringen. Dazu werfen wir einen Blick auf die einzelnen Schritte im TDD Zyklus:

Write Test Code

Das Schreiben von Testcode vor der eigentlichen Implementierung mag zunächst komisch anmuten. Es bringt jedoch den Vorteil, dass die Testabdeckung des Produktivcodes erhöht ist. Produktivcode wird nur aus dem Zweck heraus geschrieben den Testcode zu "erfüllen".

Write Functional Code

Die vorab geschriebenen Tests definieren die Anforderungen an unser Programm. Tests werden also direkt aus den Anforderungen abgeleitet. Dadurch, dass es bereits einen Test gibt, und unsere Implementierung gegen den Test geschrieben wird, stellt TDD sicher, dass die Anforderungen erfüllt sind. Der Test ist zudem eine Dokumentation für den danach geschriebenen Code. Allerdings gilt dieser Punkt auch für Unittests die nicht mittels "Test first" geschrieben wurden.

Refactor

Der letzte Schritt im TDD Zyklus ist der Refactoring Schritt. Das Design des vorab geschriebene Programmcodes wird verbessert. Sie stellen sicher, dass der Code den Zweck zum Ausdruck bringt und verständlich ist. Dass der Programmcode weiterhin korrekt ist, kann durch erneutes Ausführen der Tests einfach validiert werden. An dieser mikroskopischen Stelle ist Refactoring übrigens auch ein zulässiger Schritt. Kritischer ist Refactoring zu betrachten, wenn es zu einem späteren Zeitpunkt durchgeführt wird, oder mehrere Codestellen betrifft (siehe "Vorsicht wenn Entwickler den Begriff Refactoring verwenden").

Nachteile und Lösung

TDD ist nicht prinzipiell schlecht. Allerdings proklamieren viele Befürworter von TDD, dass die Entwicklung in Baby-Steps und das Schreiben des Testscodes vor dem Produktivcode, zu einem "speziellen Softwaredesign" führt (was auch immer das genau bedeuten mag). Klar ist: dadurch, dass der Test vor der Implementierung geschrieben wird, ist ein Entwickler dazu gezwungen seinen zukünftigen "Produktivcode" selbst zu verwenden, noch bevor es ein dritter (Kollege o.ä.) muss. Dadurch werden zumindest Usability-Probleme im Interfacedesign früh erkannt.

Durch den starken Fokus auf den zu entwickelnden Test bzw. dessen Lösung, geht jedoch auch der Blick aufs Große und Ganze verloren. Mit zunehmender Entwicklungszeit entstehen immer mehr Abhängigkeiten zwischen den einzelnen (getesteten) Units. Die Units "verweben" sich miteinander. Es entsteht Spaghetticode. Deswegen sollten Sie auch bei TDD auf die wichtige Konzeptphase (auch Definitionsphase genannt) keinesfalls verzichten. Entwerfen Sie das Softwaredesign auf höherer Flugebene gemeinsam im Team - und setzen Sie die Lösung dann auf niedrigerer Flugebene um, gerne mit TDD.

Der Unterschied: Dependency Inversion Principle vs. Dependency Injection

2022-02-04T00:00:00Z

Die Begriffe Dependency Injection und Dependency Inversion Principle werden häufig verwechselt, oder die Unterschiede sind nicht klar. Ganz verwirrend wird es, wenn noch der Begriff "Inversion of Control" dazukommt. Wir bringen Licht ins Dunkle.

Neulich wurde ich gefragt, was der Unterschied zwischen Dependency Injection und dem Dependency Inversion Principle ist. Im Prinzip handelt es sich um zwei komplett unterschiedliche Dinge, die man nicht direkt vergleichen kann. Aber: beim Dependency Inversion Principle kommt in der Praxis zumeist Dependency Injection zum Einsatz. Zeit, den Unterschied genau zu beleuchten.

Dependency Inversion Principle

Das Dependency Inversion Principle (DIP) ist, wie der Name schon sagt, ein Prinzip. Um genau zu sein handelt es sich um das letzte der fünf SOLID Prinzipien. Das sind fünf Prinzipien für das Design von objektorientierter Software. Das Ziel der SOLID Prinzipien ist es, das innere Design von Softwareprodukten unkompliziert und erweiterbar zu gestalten.

Für die Masse der Entwickler, die objektorientiert arbeiten, erkläre ich DIP ganz anschaulich an folgendem Beispiel: Ein Autofahrer soll verschiedene Fahrzeuge fahren können: einen Schaltwagen, einen Automatikwagen und ein selbstfahrendes Auto.

Eine mögliche Implementierung (die aber gegen das DIP verstößt!) könnte wie folgt aussehen. Zunächst werfen wir einen Blick auf die Klassen der jeweiligen Autos. Wir fangen mit dem Schaltwagen an, dessen Implementierung für sich gesehen zunächst logisch aussieht. Der Schaltwagen bietet verschiedene Methoden an. Neben der Möglichkeit einen Gang hochzuschalten, gibt es auch Methoden zum "drücken" oder "loslassen" der Kupplung:

public class ManualCar
{
    public void Start()
    {
        // Code...
    }

    public void Stop()
    {
        // Code...
    }

    public void PressClutch()
    {
        // Code...
    }

    public void ReleaseClutch()
    {
        // Code...
    }

    public void Upshift()
    {
        // Code...   
    }

    public void Downshift()
    {
        // Code...
    }
}

Das folgende Listing zeigt die Klasse für den Automatikwagen. Auch dieser scheint für sich genommen richtig implementiert. Da unser Fahrer keine Kupplung betätigen kann, gibt es lediglich die Möglichkeit zum Umschalten des sog. "Sportmodus":

public class AutomaticCar
{
    public void Start()
    {
    }

    public void Stop()
    {
    }

    public void ChangeMode(bool isSportMode)
    {
    }
}

Unser autonom fahrendes E-Auto ist der Knaller! Wir müssen es nicht einmal an- oder ausschalten. Das Fahrzeug ist so intelligent, dass es zwischen An und Aus wechselt sobald jemand im Fahrzeug sitzt. Den Elektromotor müssen wir sowieso nicht "starten":

public class SmartCar
{
    public void ChangeMode(bool isSportMode)
    {
    }
}

Spannend wird jetzt die Implementierung des Fahrers. In Abhängigkeit des jeweiligen Fahrzeuges muss der Fahrer unterschiedliche Methoden seines Autos aufrufen. Bedenken Sie bitte, dass ich aktuell noch die Problemstellung verdeutlichen möchte und wir gleich zu einer bessern Lösung kommen.

Die Fahrer-Klasse entscheidet Mittels des Enums, um welche Art von Auto es sich handelt:

public enum Cars
{
    ManualCar,
    AutomaticCar,
    SmartCar
}

public class Driver
{
    public Driver(ManualCar manualCar, AutomaticCar automaticCar, SmartCar smartCar)
    {
        ManualCar = manualCar;
        AutomaticCar = automaticCar;
        SmartCar = smartCar;
    }

    public ManualCar ManualCar { get; set; }
    public AutomaticCar AutomaticCar { get; set; }
    public SmartCar SmartCar { get; set; }

    public Cars SelectedCar { get; set; }

    public void Start()
    {
        switch (SelectedCar)
        {
            case Cars.ManualCar:
            {
                ManualCar.PressClutch();
                ManualCar.Start();
                ManualCar.ReleaseClutch();
                break;
            }
            case Cars.AutomaticCar:
            {
                AutomaticCar.Start();
                break;
            }
            case Cars.SmartCar:
            {
                // do nothing (starts if driver enteres car)
                break;
            }
        }
    }

    public void Stop()
    {
        switch (SelectedCar)
        {
            case Cars.ManualCar:
            {
                ManualCar.Stop();
                break;
            }
            case Cars.AutomaticCar:
            {
                AutomaticCar.Stop();
                break;
            }
            case Cars.SmartCar:
            {
                // do nothing (stops if driver leaves car)
                break;
            }
        }
    }

    public void Upshift()
    {
        switch (SelectedCar)
        {
            case Cars.ManualCar:
            {
                ManualCar.PressClutch();
                ManualCar.Upshift();
                ManualCar.ReleaseClutch();
                break;
            }
            case Cars.AutomaticCar:
            {
                AutomaticCar.ChangeMode(false);
                break;
            }
            case Cars.SmartCar:
            {
                SmartCar.ChangeMode(false);
                break;
            }
        }
    }

    public void Downshift()
    {
        switch (SelectedCar)
        {
            case Cars.ManualCar:
            {
                ManualCar.PressClutch();
                ManualCar.Upshift();
                ManualCar.ReleaseClutch();
                break;
            }
            case Cars.AutomaticCar:
            {
                AutomaticCar.ChangeMode(true);
                break;
            }
            case Cars.SmartCar:
            {
                SmartCar.ChangeMode(true);
                break;
            }
        }
    }
}

Leider haben die unterschiedlichen Autos zu einer Art Code Duplikation geführt. Der Code ist nie exakt gleich, aber immer sehr ähnlich. Mittels eines einfachen Extract Method Refactorings lässt sich dieser Code Smell nicht entfernen. Switch-Case Statements sind ein typisches Indiz dafür, dass das Dependency Inversion Principle verletzt ist. Die Anwendung wird schnell unwartbar. Wir müssen perspektivisch überall mit switch-case die Fahrzeuge unterschiedlich ansprechen. Ist Ihnen aufgefallen, dass in der Downshift-Methode des Fahrers beim Schaltwagen die Upshift Methode aufgerufen wird (Copy-Paste Fehler!)? Unsere Realisierung ist also nicht nur schlecht zu warten und zu erweitern, sondern auch noch fehleranfällig.

Das Problem ist übrigens nicht, dass die Autos unterschiedlich sind, sondern dass sich der Fahrer um die jeweilige Unterscheidung kümmern muss. Die Abhängigkeit des Fahrers zu den Autos ist zu stark.

Jetzt ist es Zeit für die Definition des DIP.

Das DIP ist definiert mit:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Vereinfacht ausgedrückt, sagt es aus, dass alle "Teile" unserer Anwendung immer nur von Abstraktionen, aber nicht von der konkreten Realisierung abhängig sein sollten. Für Klassen bedeutet das, dass sie keine Referenzen auf andere konkrete Klassen, sondern zu deren Interfaces besitzen sollen. Sind diese Interfaces nicht vorhanden, müssen sie eingeführt werden. Da es sich um ein Prinzip handelt, sollte es so weit irgendwie möglich immer eingesetzt werden.

Für unser Beispiel bedeutet das, dass wir eine Abstraktion eines Autos einführen:

public interface ICar
{
    void Start();
    void Stop();
    void IncreaseDynamic();
    void DecreaseDynamic();

    string GetDestination();
}

TIPP: Definieren Sie Abstraktionen immer aus Sicht des Verwenders! Abstraktionen dienen dazu, ein (möglichst sinnhaftes) Verhalten für den Konsumenten bereitzustellen und die Implementierungsdetails hinter einer Sinnvollen Schnittstelle quasi zu "verstecken".

Der Fahrer interessiert sich in unserem Beispiel nicht für die Details des Autos. Er will seinen Zweck erfüllt haben. Unser Fahrer will nicht unbedingt hoch- oder herunterschalten. Was unser Fahrer wirklich will, ist dynamischer oder komfortabler fahren.

Am Beispiel des Schaltwagens zeigt sich, dass trotzdem die fahrzeugspezifische Logik abgebildet werden kann (und ja auch muss). Die Methoden PressClutch() und ReleaseClutch() werden jetzt einfach innerhalb von Increase- bzw. DecreaseDynamic() aufgerufen.

public class ManualCar : ICar
{
    public void Start()
    {
    }

    public void Stop()
    {
    }

    public void IncreaseDynamic()
    {
        PressClutch();
        DownShift();
        ReleaseClutch();
    }

    public void DecreaseDynamic()
    {
        PressClutch();
        UpShift();
        ReleaseClutch();
    }

    private void PressClutch()
    {
    }

    private void ReleaseClutch()
    {
    }

    private void UpShift()
    {   
    }

    private void DownShift()
    {
    }
}

public class SmartCar : ICar
{
    public void Start()
    {
    }

    public void Stop()
    {
    }

    public void IncreaseDynamic()
    {
        ChangeMode(true);
    }

    public void DecreaseDynamic()
    {
        ChangeMode(false);
    }

    private void ChangeMode(bool isSportMode)
    {
    }
}

Der Code der Driver-Klasse erfährt jetzt eine massive Vereinfachung. Er kann einfach nur die Abstraktion verwenden. Das ist pure Eleganz und zeigt die Mächtigkeit des Dependency Inversion Principles:

public class Driver
{
    private readonly ICar _car;

    public Driver(ICar car)
    {
        _car = car;
    }

    public void Start()
    {
        _car.Start();
    }

    public void Stop()
    {
        _car.Stop();
    }

    public void IncreaseDynamic()
    {
        _car.IncreaseDynamic();
    }

    public void DecreaseDynamic()
    {
        _car.DecreaseDynamic();
    }
}

Unser Programm würde sich bei einer neuen Fahrzeugklasse auch problemlos erweitern lassen. Das neue Fahrzeug muss nur ebenso unsere Schnittstelle ICar implementieren und wir müssen nicht hunderte von Stellen, Switch-Case Statements, If-Else, usw. im Programmcode anpassen. Unser High-Level Modul Fahrer ist jetzt nicht mehr von den Low-Level Modulen (den Autos) abhängig. Stattdessen sind beide von der Abstraktion des Autos - dem Interface - abhängig. Der Fahrer ist vom Interface abhängig, da er es anstelle des konkreten Typs verwendet. Die Autos sind vom Interface abhängig, da sie dessen Schnittstelle realisieren.

Die Abhängigkeiten verlaufen jetzt nicht mehr von "oben nach unten" sondern (zumindest teilweise) "bottom to top". Teilweise, weil der Fahrer immer noch von dem Interface abhängig ist. Dieses Interface ist aus komponentenorientierter Sicht auf Ebene der Autos zu sehen. Meine persönliche Meinung ist daher, dass die Abhängigkeiten beim Dependency Inversion Principle nicht umgedreht (to invert) werden, sondern eigentlich eher eine "Umlenkung" über das Interface existiert.

Fakt ist aber, dass die Abhängigkeit zu den konkreten Typen nicht mehr explizit existiert. Man könnte auch von einer schwachen Abhängigkeit sprechen.

Wenn Sie sich für eine ausführliche Erklärung über die SOLID Prinzipien interessieren, dann empfehle ich Ihnen gerne unsere 5 teilige Artikelserie auf informatik-aktuell.de. Mein Kollege Andre Krämer und ich, erklären die SOLID Prinzipien anhand eines durchgängigen Beispiels. Aus didaktischen Gründen fangen wir in der Artikelserie sogar beim Dependency Inversion Principle an.

Dependency Injection

Bei Dependency Injection (DI) handelt es sich nicht um ein Prinzip, sondern vielmehr um eine Technologie. Viele moderne Frameworks wie z.B. Angular bieten Out Of The Box Unterstützung für DI. Das Framework - oder ein dedizierter "DI-Container" - unterstützt uns dabei die Abhängigkeiten in unserer Anwendung flexibel und dynamisch (zur Laufzeit) aufzulösen.

Die Begrifflichkeit "inject" (injizieren) ist entscheidend. Dependency Injection folgt dem "Inversion Of Control" Pattern. Unsere Klassen sollen sich nicht um die Auflösung der Abhängigkeiten kümmern. Stattdessen werden diese, z.B. durch Konstruktorparameter, Getter, Setter usw. vom Dependency Injection Framework an unsere Klasse übergeben. Beim Bootstrappen unserer Anwendung werden dabei Abstraktionen und deren Realisierung am Dependency Injection Framework registriert. Dann kann der DI-Container verwendet werden, um eine Einstiegsklasse o.ä. aufzulösen. Diese besitzt logischerweise Abhängigkeiten zu ersten Abstraktionen. Deren Realisierungen wieder zu anderen Abstraktionen usw. Alle diese Abhängigkeiten werden dann vom DI Container instanziiert und aufgelöst. Der DI Container spannt sozusagen ein ganzes Abhängigkeitsnetz auf. DI besitzt noch mehr Vorteile. Diese behandeln wir z.B. ausführlich in unserer Clean Code Schulung.

Fazit

Durch das Dependency Inversion Principle erhalten wir wartbaren und erweiterbaren Code. Anstelle von starken Abhängigkeiten zu konkreten Typen, besitzen unsere Klassen Abhängigkeiten zu Abstraktionen. Die Abhängigkeiten verschwinden nicht ganz. Sie werden nur schwächer und unser Programm wird wartbar und erweiterbar. Durch Dependency Injection, können die Abhängigkeiten zu Abstraktionen dynamisch, d.h. zur Laufzeit aufgelöst werden.

Codelution auf den IT-Tagen 2023!

2024-03-22T00:00:00Z

Zum ersten Mal waren wir im Dezember 2023 nicht nur mit einem Vortrag, sondern auch mit unserem eigenen Stand auf den IT-Tagen in Frankfurt vertreten, eine der größten IT-Konferenzen für Software-Entwicklung, -Architektur, DevOps, KI, Datenbanken, IT-Security, Agile und IT-Management. Ein bunter Mix aus 220 spannenden Vorträgen, interessanten Ausstellern, eine Menge wissensdurstiger Besuchern und einem abwechslungsreichen Abendprogramm 😊

Wir konnten uns dort nicht nur mit unserem nagelneuen Stand präsentieren, sondern auch fachlich einen echten Mehrwert bieten. Stefan hat den Zuschauern in seinem Vortrag „SOLID-Hardcore“ im Turbospeed die 5 Solid-Prinzipien anhand eines leicht verständlichen Beispiels erklärt und auf unterhaltsame Art und Weise sein Expertenwissen komprimiert in 45 Minuten vermittelt.

Die Interessen der Besucher waren vielfältig und wir konnten in den Gesprächen am Stand über die aktuellen Bedarfe in den Entwicklerteams, Trends und Neuerungen sprechen.

Nach wie vor ist das Thema Clean Code für viele Softwareentwickler ein spannendes Thema in Bezug auf erfolgreiche, effektive und nachhaltige Projekte genauso wie die Wartbarkeit und Erweiterbarkeit von Code und Effizienz innerhalb des Teams.

Aber auch das Thema Git ist auf großes Interesse gestoßen. Viele Unternehmen setzen das Versionsverwaltungssystem noch nicht oder nicht richtig ein.

Wir konnten den interessierten Besuchern am Stand einen kleinen Überblick über unser Schulungsportfolio geben und über Herausforderungen in den Teams und in den Projekten sowie Lösungsmöglichkeiten sprechen.

Das Abendprogramm war ebenfalls sehr unterhaltsam gestaltet, neben Bier und Snacks gab es ein Tischkicker-Turnier mit der aktuellen Weltmeisterin und Zeit für Austausch auch außerhalb des Entwickler-Alltags.

Vorne hui, innen pfui? UI/UX-Projekte nachhaltig aufbauen!

2024-04-29T00:00:00Z

Ein tolles UI-Design ist ein Anfang. Aber ist es auch nachhaltig strukturiert bzw. umgesetzt?

Nur durch nachhaltige Lösungen können wir langfristigen Erfolg sicherstellen.

Erweiterbarkeit, Wartbarkeit und Wiederverwendbarkeit sind auch im Frontend unabdingbar. In diesem Blogartikel werfen wir einen Blick auf den Aufbau von Frontend-Projekten. Je weiter wir im Blogartikel kommen, umso exklusiver werden die Prinzipien, die wir kennenlernen. Wir enthüllen Techniken, die Sie so auch bei großen Designagenturen nicht bekommen.

Die Basis: der Styleguide

Am Anfang unseres Blogartikels steht ein schönes UI-Design. Zum Beispiel in Form eines Styleguides. Der Styleguide dient als Spezifikation für die Umsetzung. Er enthält Farbdefinitionen oder beschreibt die Typographie. Also Schriftarten, Schriftgrößen oder Schriftschnitte. Ein Styleguide beschreibt auch das Design von Oberflächenelementen. Bei modernen Softwareprojekten ist ein Styleguide unerlässlich. Bei Codelution setzen wir diese Art der UI-Spezifikation deswegen als Minimum ein. Besser wäre es noch, den Styleguide zum Designsystem weiterzuentwickeln, aber das sprengt den Rahmen dieses Artikels.

Ein einfacher Styleguide muss nicht aufwändig sein. Hier sehen wir ein Beispiel mit 21 Seiten:

Daran können wir schon das erste Best-Practice für ein erfolgreiches Frontend Projekt erkennen:

Best-Practice #1:

Der Styleguide muss konsistent umgesetzt werden.

Hierzu sollte ein UI-Designer in die Entwicklung eingebunden werden. Der UI-Designer sollte die Arbeit der Entwickler reviewen. Wie ein Code Review sollte das Design Review regelmäßig durchgeführt werden - z.B. regelmäßig während der Sprints und auch wenn die Entwickler keine Rückfragen haben. Das geschulte Auge eines Profis lässt sich nicht einfach ersetzen.

Als nächstes stehen die Ziele Wiederverwendbarkeit, Erweiterbarkeit und Wartbarkeit an.

Der Schlüssel zur Wiederverwendbarkeit liegt in einer sinnvollen Modularisierung.

Softwareentwickler sind Modularisierung eigentlich gewöhnt. Interessant wird es im Bereich UI. Hier findet die Modularisierung nicht nur anhand der Domäne (Fachlichkeit) statt - wichtig ist auch noch die "Integrationstiefe". Konkret heißt das, dass wir zwischen Smart Components und Dumb Components unterscheiden.

Smart Components sind unsichtbare UI-Bausteine mit Domäne - also Geschäftslogik. Dumb Components sind primitive Oberflächenelemente, z.B. Steuerelemente (UI-"Controls") wie Textfelder und Buttons. Diese haben keine Logik.

Best-Practice #2:

Bei der Modularisierung zwischen Smart- und Dumb-Components trennen.

Smart Components verwenden Dumb Components (oder andere Smart Components). Dumb Components verwenden niemals Smart Components. Dumb Components empfangen Eingabedaten des Benutzers und übergeben diese an ihre Smart Components. Umgekehrt können Smart Components Daten an ihre Dumb Components übergeben, damit diese dem Benutzer angezeigt werden (Beispiel eine Label-Komponente).

Die Schachtelung von Smart und Dumb Components könnte dann ungefähr so aussehen (die Smart Components sind hier in türkis hervorgehoben, die Dumb Components in rot.:

An dieser Stelle werfen wir einen Blick auf die typische Modularisierung einer Anwendung. Die sog. Shell definiert den Rahmen, das Grundgerüst unserer Anwendung.

Die Anwendung ist weiter in Feature Module unterteilt. Bei modernen Webanwendungen werden diese "lazy" - also erst bei Bedarf vom Webserver geladen.

Die Featuremodule greifen auf geteilte Komponenten und Services zurück - z.B. in einem oder mehreren Domäne Modul/en.

Die Featuremodule und das/die Domänemodul/e sind die Stellen, in denen die Smart Components kodiert sind. Die Dumb Components sind auf einer tieferen Schicht kodiert, z.B. in einer Widget Bibliothek.

Die Referenzen verlaufen von oben nach unten:

Vor wenigen Jahren haben wir die Dumb Components noch technologiespezifisch umgesetzt. Bei Angular beispielsweise mit Widget Libraries. Der aktuelle Stand der Technik sind aber HTML5 Webcomponents. Diese sind "webtechnologieagnostisch" und können Framework übergreifend eingesetzt werden (Angular, React, Vue, ...). HTML5 Webcomponents können z.B. mit Lit.dev entwickelt werden.

Best-Practice #3:

Frameworkunabhängige Dumb Component Libraries auf Basis von HTML5 Webcomponents entwickeln.

Grundvoraussetzung für eine einfache Erweiterbarkeit ist die Modularisierung unserer Anwendung.

Eine Dumb Component Library, nennen wir sie "Widget-Library" lässt sich zentral erweitern und alle Konsumenten der Library können von den neuen Erweiterungen profitieren. Es versteht sich von selbst, dass bei größeren Softwaresystemen die Widget-Library wie ein eigenes Produkt versioniert, packetiert usw. werden sollte.

Jetzt gehen wir auf einen noch unbekannteren Aspekt der Widgets ein: ihrem übergeordneten Verwendungszweck - ihrem "superordinate type" sozusagen. Das bedeutet, dass wir unsere UI-Widgets kategorisieren und zwar nach: Struktur (also Layouting Components) und Verhalten (Behavior Components).

Best-Practice #4:

UI Widgets nach strukturellen Komponenten und Verhaltenskomponenten trennen.

Das heißt nicht, dass getrennte Widget Libraries für Structural oder Behavioral Components benötigt werden, sondern, dass bei der Kodierung der Komponenten die Aspekte Layout und Interaktion getrennt werden sollten.

Bleibt noch die Wartbarkeit als hegeres Ziel unseres "Softwaredesigns". Ein häufiges Problem bei der Entwicklung von UI Libraries ist, dass das Styling nicht von der strukturellen Definition der eigentlichen UI-Controls getrennt wird.

Für unser neues Projekt wollen wir aber nicht von vorneherein die Fehler für das nächste historisch gewachsene Softwareprodukt machen. Der nicht-funktionale Aspekt der Wartbarkeit soll wirklich im Vordergrund stehen.

Wir müssen das Styling, also das Aussehen von der "Struktur und dem Verhalten" der Widgets trennen - nur so können wir später ein guten Theming usw. realisieren. Außerdem erleichtert diese Vorgehensweise ungemein spätere Änderungen im Design.

Best-Practice #5:

Styling aus UI-Controls extrahieren und von top to bottom definieren.

Bei Webtechnologien setzen Sie als eine der Möglichkeiten CSS Variablen ein. Diese lassen sich im Gegensatz zu SASS / SCSS zur Laufzeit des Programms ändern und sind damit wirklich variabel.

FAZIT

In diesem Beitrag haben Sie die Basis zum Aufbau von nachhaltigen Designsystemen gelernt. Damit Sie nicht heute das Legacy System von morgen bauen sollten die folgenden Punkte berücksichtigt werden:

Im Detail gibt es natürlich noch mehr Best-Practices, aber das ist eine solide Basis. Go for it!

Rückblick auf die DWX 2024: Codelution mittendrin!

2024-07-08T00:00:00Z

Ein voller Erfolg und viele Partien Blitzschach!

Die Developer Week (DWX) 2024, eine der bedeutendsten Konferenzen im Bereich Softwareentwicklung, fand dieses Jahr vom 01.-05. Juli im Messezentrum Nürnberg statt. Mit über 200 Vorträgen, Workshops und Keynotes von Experten aus der ganzen Welt bot die Konferenz eine Plattform für Wissensaustausch und Networking auf höchstem Niveau. In diesem Jahr war die Codelution GmbH stolz darauf, als Aussteller mit einem Messestand vertreten zu sein.

Ein Treffpunkt für Innovation und Austausch

Die DWX ist bekannt dafür, die neuesten Trends und Technologien der Softwareentwicklung zu präsentieren. Auch 2024 enttäuschte die Veranstaltung nicht: Themen wie künstliche Intelligenz, Cloud-Computing, DevOps und moderne Programmiersprachen standen im Fokus. Die Teilnehmer hatten die Möglichkeit, von den Besten der Branche zu lernen und sich über zukunftsweisende Technologien auszutauschen.

Codelution GmbH am Puls der Zeit

Unser Stand war während der gesamten Konferenz ein beliebter Treffpunkt für Entwickler, IT-Profis und Entscheidungsträger. Wir freuten uns, unsere neuesten Innovationen und Lösungen zu präsentieren, die darauf abzielen, Softwareprojekte effizienter und effektiver zu gestalten. Besonders stolz sind wir auf die zahlreichen Gespräche, die wir mit Fachleuten aus verschiedenen Branchen führen konnten. Diese Interaktionen sind für uns von unschätzbarem Wert, um die Bedürfnisse und Herausforderungen unserer Kunden noch besser zu verstehen.

Eine Partie Blitzschach als Highlight

Eine besondere Überraschung erwartete die Besucher an unserem Stand: Sie konnten eine Partie Blitzschach gegen den Geschäftsführer persönlich spielen. Diese Idee erwies sich als echter Publikumsmagnet und sorgte für viel Spaß und spannende Momente. Es war faszinierend zu sehen, wie das schnelle Schachspiel nicht nur die Köpfe rauchen ließ, sondern auch als Eisbrecher für tiefgehende technische Gespräche diente.

Inspirierende Vorträge und Workshops

Neben den Aktivitäten an unserem Stand bot die DWX 2024 eine Fülle an inspirierenden Vorträgen und Workshops. Die Themenvielfalt reichte von praktischen Tipps zur Verbesserung der Codequalität über die Implementierung sicherer Cloud-Lösungen bis hin zu innovativen Methoden im Bereich maschinelles Lernen. Jeder Vortrag bot neue Erkenntnisse und regte zum Nachdenken an. Mit den beiden Vorträgen von Stefan Dirschnabel zum Thema IOSP und SOLID konnten wir weitere Impulse für sauberen, nachhaltigen und erweiterbaren Code setzen, um so für erfolgreiche Softwareprojekte zu sorgen.

Ein herzliches Dankeschön

Wir möchten uns herzlich bei allen Besuchern unseres Messestands bedanken. Ihre Neugier, Ihr Feedback und Ihre Begeisterung haben die DWX 2024 zu einem unvergesslichen Erlebnis für uns gemacht. Wir freuen uns bereits jetzt auf die nächsten Veranstaltungen und darauf, unsere Gespräche und gemeinsamen Projekte fortzusetzen und die ein oder andere Partie Schach zu spielen!

Fazit

Die DWX 2024 war ein voller Erfolg und hat einmal mehr gezeigt, wie wichtig der Austausch und die Zusammenarbeit innerhalb der Entwicklergemeinschaft sind. Die Codelution GmbH ist stolz darauf, Teil dieser dynamischen und zukunftsorientierten Gemeinschaft zu sein. Wir sind gespannt auf die kommenden Herausforderungen und darauf, gemeinsam mit Ihnen die Zukunft der Softwareentwicklung zu gestalten.

Bleiben Sie dran und folgen Sie uns auf unseren Social-Media-Kanälen, um keine Neuigkeiten und Updates zu verpassen!

Das CODELUTION Zertifizierungssystem

2024-10-31T00:00:00Z

In den letzten Jahren ist bei CODELUTION viel passiert – doch was jetzt kommt, hebt unsere Entwicklertrainings auf ein völlig neues Level. Ab Herbst 2024 starten wir mit etwas, das uns schon lange unter den Nägeln brennt: Ein Zertifizierungssystem, das wirklich zu moderner Softwareentwicklung passt.

Warum wir das machen

Wir waren in den vergangenen Monaten auf vielen Konferenzen unterwegs – IT-Tage, Magdeburger Dev Days, DWX – und haben dort nicht nur unser Programm vorgestellt, sondern auch zugehört. Was wir immer wieder gehört haben: Es fehlt ein praxisnahes, herstellerunabhängiges System, das Skills wirklich messbar und sichtbar macht. Und genau das setzen wir jetzt um.

Rollen statt Tools – so funktioniert unser Ansatz

Während viele bekannte Zertifizierungen sich auf konkrete Technologien beschränken (Microsoft, AWS, Google usw.), gehen wir einen anderen Weg: Unsere Zertifikate richten sich nach Rollen, nicht nach Tools.

Egal ob du Frontend-Entwickler:in, Clean-Code-Profi oder DevOps-Engineer bist – bei uns steht deine Kompetenz im Vordergrund, nicht das Framework, mit dem du arbeitest. Wer heute mit Angular arbeitet und morgen React nutzt, muss sich nicht komplett neu zertifizieren lassen.

Strukturierte Lernpfade mit echten Nachweisen

Ein gutes Training ist mehr als ein einzelner Workshop. Deshalb haben wir unsere Kurse in Lernpfade gegliedert – Schritt für Schritt kannst du dich weiterentwickeln, dein Wissen vertiefen und am Ende deine Skills nachweisen. Und ja, es gibt Prüfungen – zumindest ab einem bestimmten Level. Denn wir wollen keine "Zertifikate fürs Dabeisein", sondern echten Wert schaffen.

Open Badges: Deine Qualifikation zum Mitnehmen

Nach jedem abgeschlossenen Kurs bekommst du ein Open Badge – ein digitales Zertifikat, das mehr enthält als nur ein hübsches Logo. Arbeitgeber:innen (und natürlich du selbst) sehen auf einen Blick, was du gelernt hast und wo du stehst. Die Badges sind standardisiert, fälschungssicher und lassen sich direkt in LinkedIn & Co. einbinden.

Was ist mit den bisherigen Schulungen?

Falls du schon in den letzten Jahren an unseren Trainings teilgenommen hast: Gute Nachrichten! Wir rollen das System rückwirkend aus – das heißt, auch Teilnehmende früherer Kurse (ab etwa 2021) erhalten ihre Badges automatisch. Ihr bekommt dazu bald eine E-Mail von uns.

Ein Blick in die Zukunft

Unser Kursangebot wächst stetig weiter. Ganz neu im Programm ist zum Beispiel ein Modul zu Domain-Driven Design, außerdem bauen wir aktuell den Bereich KI & Entwicklung aus. Warum? Ganz einfach: In einer Branche, in der sich Wissen in kürzester Zeit überholt, ist kontinuierliche Weiterbildung der Schlüssel – und wir wollen euch dabei bestmöglich unterstützen.

Fazit: Mehr als ein Zertifikat

Unser Ziel ist es nicht, einfach ein weiteres Zertifikatssystem auf den Markt zu bringen. Wir wollen Entwickler:innen dabei helfen, sich nachhaltig und nachvollziehbar weiterzuentwickeln – mit einem System, das zu echten Projekten, echten Rollen und echter Praxis passt.

Folge uns auf YouTube, bleib über neue Kurse auf dem Laufenden – oder sprich uns direkt an, wenn du Fragen hast.

Docker einfach erklärt

2025-05-15T00:00:00Z

Haben Sie schon mal von Docker gehört, wissen aber nicht genau, was es eigentlich ist. In diesem Beitrag unserer Einfach erklärt Serie erkläre ich Ihnen, wie Docker funktioniert und warum es für Sie und Ihr Unternehmen ein Game Changer sein kann, selbst wenn Sie kein IT-Experte sind. Am Ende zeige ich Ihnen außerdem einen praktischen Tipp, wie Sie Docker schnell und einfach ausprobieren können.

Mein Name ist Stefan Dirschnabel und ich bin Trainer für Softwareentwickler. In diesem Beitrag erkläre ich Ihnen die fünf wichtigsten Punkte über Docker.

Erstens, was es ist.
Zweitens, wie es funktioniert.
Drittens, warum Docker so beliebt ist.
Viertens, welche Vorteile Docker bringt
und fünftens, wie Sie direkt damit starten können.

Am Ende des Beitrags zeige ich Ihnen wie Sie Docker in wenigen Minuten selber ausprobieren können.

Was ist Docker?

Docker ist eine Software, die es Ihnen ermöglicht, Ihre Anwendungen und alle Abhängigkeiten der Anwendung in sogenannte Container zu verpacken. Stellen Sie sich einen Container wie eine kleine Box vor, die alles enthält, was Ihre Anwendung zum Laufen braucht. Das kann also sein: Programmcode, Bibliotheken, die Einstellung der Anwendung und so weiter und so fort. So können Sie sicherstellen, dass Ihre Software überall gleich funktioniert – egal ob auf Ihrem Laptop, in der Cloud oder auf einem Server.

Wie funktioniert Docker?

Schauen wir uns erstmal an, wie eine virtuelle Maschine funktioniert. Auf der Hardware unseres Servers oder Computers läuft bei virtuellen Maschinen eine Software, die sich Hypervisor nennt. Der Hypervisor teilt und verteilt die Hardware-Ressourcen an unsere virtuellen Maschinen.

Die virtuellen Maschinen sind also digitale Nachbildungen von physischen Maschinen – also Computern oder Servern. Virtualisierung ermöglicht es also, Hardware-Ressourcen effizient zu nutzen, Kosten zu senken und die Flexibilität zu erhöhen. Wir können Server zum Beispiel konsolidieren, Umgebungen isolieren, Software schneller bereitstellen oder auch skalieren.

Virtuelle Maschinen haben aber natürlich auch ein paar Nachteile. Wir haben zum einen den Ressourcen-Overhead, denn wir benötigen für jede virtuelle Maschine ein komplett neues Betriebssystem. Dieser Betriebssystem-Block ist immer wieder dupliziert. Außerdem haben wir eine schlechte Start-Performance, weil eben das ganze Betriebssystem immer hochfahren muss, und einen hohen Wartungsaufwand.

Docker basiert auf einer Technologie namens Containerisierung. Anders als bei virtuellen Maschinen werden nicht die ganzen Betriebssysteme immer wieder kopiert, sondern das Betriebssystem wird mit dem Host quasi geteilt, kann man sagen.

Wir sparen uns also den Betriebssystem-Block, den wir bei jeder virtuellen Maschine hatten. Dadurch sind Container viel schlanker, starten schneller und benötigen weniger Ressourcen. Die Container teilen sich den Kern des Host-Betriebssystems und sparen dadurch Platz und Rechenleistung.

Warum ist Docker so revolutionär?

Docker hat die Art und Weise, wie Software entwickelt, getestet und bereitgestellt wird, revolutioniert. Hier sind die drei Hauptgründe dafür:

Erstens: Einheitlichkeit Egal ob Entwickler, Tester oder Betreiber – jeder arbeitet mit derselben Umgebung. Das reduziert Fehler.

Zweitens: Flexibilität Docker-Container laufen überall: lokal, in der Cloud oder in hybriden Systemen.

Drittens: Effizienz Dank der schlanken Architektur können Sie mehr Anwendungen auf derselben Hardware ausführen.

Welche Vorteile bringt Docker?

Warum ist Docker so beliebt? Docker ist besonders für Unternehmen interessant, die schnell und zuverlässig neue Software ausliefern möchten.

Die wichtigsten Vorteile sind:

Schneller Start: Container starten in wenigen Sekunden.
Kostenersparnis: Weniger Ressourcenverbrauch bedeutet geringere Hardware- und Cloud-Kosten.
Einfache Skalierbarkeit: Wenn mehr Leistung benötigt wird, starten wir einfach zusätzliche Container.

Bonus: Docker selbst ausprobieren

Jetzt kommt der versprochene Bonus: Sie können Docker selbst ausprobieren. Besuchen Sie einfach docker.com und laden Sie Docker Desktop herunter. Nach der Installation von diesem Programm können Sie mit einem einfachen Befehl (docker run hello-world) einen eigenen Container starten – ganz ohne Vorkenntnisse. Das ist der erste Schritt, um in die Welt der Container einzutauchen.

Wenn Ihr Interesse geweckt ist, dann werfen Sie einen Blick auf unsere Schulung zu Docker. Ihre Wettbewerber werden ständig besser, schneller und effizienter. Für weitere spannende Erklärvideos abonnieren Sie gerne unseren Youtube Kanal.

Viel Erfolg bei der Umsetzung!

Unit Testing - HARDCORE

2025-06-03T00:00:00Z

Passend zum Vortrag auf dem Karlsruher Entwicklertag gibt's hier das zum Vortrag passende Youtube Video!

Gutes Funktionsdesign

2025-11-19T00:00:00Z

Wir Entwickler schreiben jeden Tag Funktionen und Methoden. In diesem Beitrag sprechen wir deswegen über Clean-Code-Grundlagen, gutes Funktionsdesign. Was unterscheidet gute von schlechten Funktionen?

Wenn wir in der Softwareentwicklung Funktionen entwerfen, gibt es drei zentrale Gestaltungspunkte, die den Unterschied zwischen guten und schlechten Funktionen ausmachen. In diesem Beitrag zeige ich euch, worauf es beim Funktionsdesign ankommt und wie ihr typische Fallstricke vermeidet. Ganz am Ende gibt es auch noch einen kleinen und einfachen Trick um die Lesbarkeit und Verständlichkeit deutlich zu verbessern.

Beim Funktionsdesign unterscheiden wir zwischen drei primären Gestaltungspunkten:

den Parameter die an eine Funktion übergeben werden
der Verarbeitung der Funktion
dem Rückgabewert

Parameteranzahl

Der erste Gestaltungspunkt sind die Parameter. Wichtige Fragen sind: welche Parameter werden übergeben, und wie viele?

Robert Martin unterscheidet in seinem Buch Clean Code zwischen drei Arten von Funktionen: monadischen, dyadischen und triadischen Funktionen. Martin bezieht sich hier auf die Anzahl der Parameter die an eine Funktion übergeben werden.

Monadische Funktionen

Monadische Funktionen sind Funktionen, die nur einen Parameter entgegennehmen. Diese Art von Funktion ist intuitiv sehr einfach zu verstehen. Tendenziell streben wir also eher monadische Funktionen - oder besser gesagt Funktionen mit eher weniger als vielen Parametern an.

Wenn Sie Code schreiben, werden Sie monadische Funktionen quasi automatisch in einem der folgenden Fälle verwenden:

Sie stellen eine Frage über ein Argument.
Sie wandeln ein Argument in ein anderes um.

Gute monadische Funktionen

Beispiele hierfür sind:

Frage

const isLoggedIn = isLoggedIn(user);

Umwandlung

const upperText = toUpper("lowerText");

Die hier gezeigten Beispiele sind gleichzeitig Beispiele für gute monadische Funktionen. Es gibt aber auch Grenzfälle.

Grenzfälle

Die folgende Funktion ist schon nicht mehr so schön:

enableFeature(FEATURE.REPORTING);

Zwar handelt es sich um eine monadische Funktion, allerdings besitzt diese keinen Rückgabewert. Es muss also irgendetwas spezielles in der Funktion "passieren". Von außen, also als Verwender, ist dieses "passieren" nicht so einfach zu erkennen. Es hilft nur eins: Sie müssen in die Funktion "reinspringen" und nachsehen, was genau gemacht wird. Dieses Springen, von Funktion zu Funktion, ist ein typisches Zeichen dafür, dass der Abstraktionsgedanke des "Moduls Funktion" nicht verständlich genug ist.

Merke: besser sind Funktionen mit einem klaren Rückgabewert. Allerdings handelt es sich bei uns um einen Grenzfall, denn in unserem Szenario werden andere Systemteile per Event-Mechanismus über das aktivierte Feature benachrichtigt. In so einem Event Fall, können Sie keinen sinnvollen Rückgabewert definieren.

Schlechte monadische Funktionen

Eher nicht empfehlenswert sind monadische Funktionen wie zum Beispiel:

mergeDefaultConfig(config);

Was passiert hier wirklich? Wenn die Funktion keinen Rückgabewert liefert (wonach es aussieht), dann verändert sie die "config". Dieses Verhalten kann schnell übersehen werden und dann zu unerwarteten Effekten im Programmablauf führen. Besser und klarer ist es immer nach dem EVA-Prinzip zu arbeiten, also mit Eingabe (Parameter), Verarbeitung, Ausgabe (Rückgabewert).

Dyadische Funktionen

Funktionen mit zwei Parametern sind gang und Gäbe in der Entwicklung. Die Parameter sollten dabei in einem inhaltlichen Bezug zueinander stehen.

Gute dyadische Funktionen

const sum = add(1,2);
const origin = new Point(0,0);

Grenzfälle

Es mag sich banal anhören, aber bedingt durch die zwei Parameter, wird die Verständlichkeit sofort deutlisch schwerer - besonders wenn der Namen der Funktion nicht wirklich optimal ist. Wer gewinnt die Konfliktauflösung beispielsweise im folgenden Fall? Die localVersion oder die remoteVersion?

const version = resolveConflictBetween(localVersion, remoteVersion);

Schlechte dyadische Funktionen

moveTo(origin.xCoordinate, origin.yCoordinate);

Bessere dyadische Funktionen

Es gibt einfache Mechanismen die Sie anwenden können um schlechte oder schwer zu verstehende (Grenzfälle) dyadische Funktionen direkt zu verbessern:

const version = resolveConflictAndPreferLocalVersion(localVersion, remoteVersion); // klares Naming

moveTo(origin); // zwei Parameter mittels eines Datenobjekts vereinfachen

Das Beispiel mit moveTo ist besonders ärgerlich, denn augenscheinlich gab es bereits eine Point Datenstruktur, aber diese wurde einfach nicht verwendet.

Merke: reduziere die kognitive Last für den Verwender durch gutes Naming oder durch das Zusammenführen von vielen zu wenigeren Parametern.

Triadische Funktionen und mehr

Eine berechtigte Frage ist nun, wieviele Parameter wir noch tolerieren wollen? Prinzipiell ist es immer schwierig eine pauschale Aussage zu treffen, aber der Beratersatz "es kommt darauf an" hilft natürlich auch niemandem weiter. Ich würde für mich die Grenze daher bei 3-4 Parametern ziehen.

Funktionen mit mehr Parametern werden schnell sehr unintuitiv, müssten wahrscheinlich aufgeteilt werden, und sind wenn, dann nur in begrenztem lokalen Scope zulässig. Zum Beispiel als private Methoden innerhalb einer Klasse.

Bei wichtigen öffentlichen Methoden, oder Komponenten Kontrakten, sollten Sie klare Datenobjekte (im Zweifelsfalle auch Command oder Query Objekte) einführen, um die Lesbarkeit zu gewährleisten und das Verständnis durch den Namen des Datentyps zu verbessern.

Dies ist auch das allgemeine Pattern, das Sie immer anwenden können um zwischen den verschiedenen Funktionstypen zu "wechseln".

Anzahl Rückgabewerte

Mit dem Rückgabewert verhält es sich so ähnlich wie mit den Parametern. Ein klarer Rückgabewert ist besser als die Rückgabe von mehreren Werten mittels z.B. eines generischen Datencontainers (Tuple / Pair, Tripple, Quadrupel, ...). Anstelle eines generischen Datencontainers könnte hier auch Array, anonymes Objekt o.ä. stehen.

Wenn bei einem Rückgabewert stattdessen ein klarer Datentyp verwendet wird sorgt dies für besseres Verständnis bei den Verwendern unserer Methode. Und denken Sie daran: Code wird viel öfter gelesen und verwendet, als geschrieben (nur 1-mal).

Allerdings haben generische Datencontainer teilweise trotzdem ihre Berechtigung. Tendenziell würde ich aber versuchen Ihre Verbreitung im System zu reduzieren. Denn wenn der Context größer wird, wird es immer schwerer zu verstehen, für was der Tuple denn genau steht - immerhin trägt er keinen klaren Namen und durchläuft eine Art "Flüsterpost" wenn er von Variable zu Variable zugewiesen wird und dabei das Naming Stück für Stück degradiert...

Parameter- und Rückgabetyp

Neben der Parameteranzahl ist der Typ des Parameters bzw. des Rückgabewerts selbst ein interessantes Modellierungskriterium.

Parameter: den Parametertyp unserer Funktion/Methode möchten wir dabei so allgemein, also so unspezifisch wie möglich halten. Wenn wir beispielsweise die Preise einer Auflistung von Tellern berechnen wollen, bietet es sich an für den Parametertyp die kleinste gemeinsame Basisklasse des Auflistungstyps zu verwenden:

public double AddPrices(IEnumerable<Dish> dishes>) {
// ...
}

Der Vorteil für den Verwender ist jetzt, dass er im Aufruf der AddPrices Funktion sehr flexibel ist. Er kann übergeben: Array, List, Set, ... - solange die Auflistung die er verwendet eben vom Typ IEnumerable ist.

Rückgabewert: den Rückgabewert sollten wir so spezifisch wie nötig halten. Beispiel:

OpenCsvFile("myFile.csv"): CsvFile // CsvFile extends File, Rückgabewert aber CsvFile

Erstens möchte der Verwender klar eine Csv Datei öffnen und zweitens würde er wenn wir File zurückgeben nicht an CsvFile spezifische Informationen (wie z.B. das Trennzeichen) kommen können.

Seiteneffekte

Von einem Seiteneffekt spricht man dann, wenn die Funktion unerwartete, quasi versteckte Effekte ausführt. Die Funktion lügt uns sozusagen an. Die folgende Funktion suggeriert durch ihren Namen lediglich das Aktualisieren der EMail Adresse, tatsächlich wird aber auch noch eine E-Mail Benachrichtigung verschickt.

function updateUser(userId: string, newEmail: string): void {
  const user = userRepository.getUser(userId);
  if (!user) return;

  const oldEmail = user.email;
  user.email = newEmail;
  userRepository.save(user);

  try {
    // Seiteneffekt: externer Call
    notificationService.sendEmailChangeNotification(oldEmail, newEmail);
  } catch (err) {
    // ...
  }
}

Besser wäre es gewesen das Verschicken der Notification raus zu ziehen und updateUser gefolgt von sendEMailChangeNotification in einem "UpdateUserEMailUseCase" aufzurufen.

Fazit

Wir Entwickler schreiben jeden Tag Funktionen. Das Wissen um gutes Funktionsdesign sollte daher zum Standardrepertoire eines jeden Entwicklers gehören. Gute Funktionen führen dazu, dass Sie Ihren Quellcode nicht "lesen und interpretieren" müssen, sondern dass Sie Ihr Programm "lesen und verstehen" können.

Wir haben in der Vergangenheit bereits tausende Entwicklerteams in genau diesen Bereichen geschult. Lassen Sie uns gerne sprechen, wir freuen uns jederzeit über Ihren Anruf.

CODE & BEER in Karlsruhe

2026-09-01T00:00:00Z

Drei Talks, gute Gespräche und ein Bier danach

Softwareentwicklung besteht nicht nur aus Code. Es geht um gute Entscheidungen, funktionierende Zusammenarbeit und die Frage, wie wir Software langfristig verständlich, wartbar und zuverlässig halten.

Genau darum geht es bei CODE & BEER.

Am 29. Oktober 2026 veranstalten wir von Codelution zum ersten Mal einen kleinen Entwicklerabend in Karlsruhe. Drei technische Talks, anschließend Bier und Fingerfood, dazu Zeit für Gespräche mit anderen Entwicklern und IT-Interessierten aus Karlsruhe und Umgebung.

Die Teilnahme ist kostenlos, die Plätze sind allerdings begrenzt.

👉 Hier kostenlos für CODE & BEER anmelden!

Drei Talks - drei Perspektiven auf moderne Softwareentwicklung

Für unseren ersten CODE & BEER Abend haben wir drei Themen ausgewählt, die Softwareentwickler in ihrem Alltag regelmäßig beschäftigen: Versionsverwaltung, Softwarearchitektur und der Betrieb moderner Anwendungen.

🪼 Was ihr über Git nicht wisst

Git gehört inzwischen zum Standardwerkzeug praktisch jedes Entwicklerteams. Trotzdem gibt es einige Funktionen, bei denen selbst erfahrene Entwickler gelegentlich überlegen müssen:

Was passiert eigentlich bei einem Rebase? Warum entstehen dabei Konflikte? Was genau macht ein Cherry-Pick? Und was bedeutet History-Rewriting eigentlich?

Unter dem Titel „Was ihr über Git nicht wisst“ geht es nicht darum, möglichst viele Git-Befehle auswendig zu lernen. Stattdessen stellt Florian das Grundprinzip hinter Git in den Mittelpunkt.

Wer versteht, wie Git seine Historie tatsächlich organisiert, kann viele der vermeintlich komplizierten Funktionen plötzlich nachvollziehen.

Rebase und Cherry-Pick werden dann nicht mehr zu mysteriösen Befehlen, die man irgendwo aus einer Dokumentation kopiert, sondern zu Werkzeugen, deren Verhalten man verstehen und bewusst einsetzen kann.

ZUR ANMELDUNG

🏗️ Architekturmuster endlich verstehen

Monolith, Modulith, Layered Architecture, Clean Architecture und dann gibt es auch noch Begriffe wie Dependency Inversion und IODA.

Bei Softwarearchitektur kann man schnell den Eindruck bekommen, dass es für jedes Problem noch ein weiteres Pattern gibt.

Stefan möchte deshalb einen Schritt zurückgehen und die grundlegenden Konzepte miteinander vergleichen.

In seinem Talk „Architekturmuster endlich verstehen“ geht es nicht darum, das nächste Architektur-Pattern zu verkaufen. Stattdessen werden die wichtigsten Ansätze Schritt für Schritt gegenübergestellt.

Eine gute Softwarearchitektur sollte nicht möglichst viele Schichten, Abstraktionen und Patterns enthalten. Entscheidend ist, ob sie dabei hilft, ein System wartbar, erweiterbar und verständlich zu halten.

ZUR ANMELDUNG

📦Von Code zu Container: Docker in der Praxis:

Container auf Linux-Basis sind heute ein etablierter Standard, wenn es um den Betrieb moderner Backend-Anwendungen geht. Sie schaffen eine flexible und konsistente Umgebung, in der eine Anwendung inklusive ihrer benötigten Abhängigkeiten bereitgestellt werden kann.

Der große Vorteil: Ein Container bringt alles mit, was zum Ausführen der Anwendung benötigt wird – auf dem Zielsystem wird im Wesentlichen nur eine passende Container-Runtime benötigt. Dadurch lassen sich Anwendungen flexibel betreiben, egal ob auf der eigenen Entwickler-Maschine, im Rechenzentrum oder in der Cloud.

ZUR ANMELDUNG

Softwareentwicklung muss nicht trocken sein

CODE & BEER soll bewusst ein entspannter Nachmittag sein.

3 Talks. Gute Gespräche. Bier. Fingerfood. Schach.

CODE & BEER - alle Infos auf einen Blick

📅 29. Oktober 2026

🕓 ab 16 Uhr

📍 CyberForum Church, Karlsruhe

🎤 3 technische Talks

🍺 Bier

🥨 Fingerfood

♟️Schach

💬 Networking mit Entwicklern und IT-Interessierten aus Karlsruhe und Umgebung

🎟️ Kostenlose Teilnahme

Die Teilnehmerzahl ist begrenzt. Die Anmeldung ist bis zum 16.10. möglich

👉 Jetzt kostenlos anmelden!

Wir freuen uns auf euch bei CODE & BEER in Karlsruhe! 🍺