Macht der Craft Matthias Alt & Alexandre Soler Sanandres

In dieser Episode von "Die Macht der Craft" tauchen wir tief in das Thema der Planung in der Softwareentwicklung ein. Wir vergleichen Big Design Upfront und No Design Upfront Ansätze und analysieren ihre Vor- und Nachteile. Dabei betonen wir die Bedeutung eines ausgewogenen Ansatzes, der je nach verschiedenen Faktoren variiert. Wir diskutieren auch, wie die Entwicklungs-Methodik, Erfahrungslevel des Teams und Kundenfeedback das benötigte Design Upfront beeinflussen können. Am Ende zeigen wir, dass eine Mischform beider Ansätze oft die beste Lösung ist, um individuellen Anforderungen gerecht zu werden und eine effektive Planung zu gewährleisten.

In dieser Episode von "Die Macht der Craft" dreht sich alles um Design Sprints. Unser Gast Stefan Bierwirth erklärt, dass ein Design Sprint eine Möglichkeit ist, Kundenfeedback zu Ideen innerhalb von 5 Tagen zu erhalten, ohne das Produkt bauen oder Monate an Arbeit investieren zu müssen. Ein Design Sprint sollte für wichtige Themen mit hoher Priorität eingesetzt werden, wenn noch keine Lösung vorhanden ist und das Ergebnis noch offen ist.



In einigen Fällen werden Tag 1 und Tag 2 zu einem Tag zusammengelegt, um den Design-Sprint auf vier Tage zu verkürzen. Die Auswahl hängt von der Komplexität des Problems und der Erfahrung der Teilnehmer ab. Das wichtigste beim Design-Sprint sind die Teilnehmer. Ein Team von etwa sieben Personen mit verschiedenen Fähigkeiten wie UX-Designern, Requirements-Engineers, Software-Entwicklern, Architekten, Marketingleuten und Kundenbetreuern wird empfohlen, um verschiedene Blickwinkel einzubringen und alle Stimmen zu hören.

In dieser Episode haben wir Code Smells besprochen und wie man sie vermeidet. Dazu gehören längere Methoden, schlechte Klassennamen und unnötige Abhängigkeiten. Wir haben auch über die Verwendung von komplexen Typen und Tools wie statischer Codeanalyse gesprochen. Wichtig ist qualitativ hochwertiger Code mit guter Namensgebung und klaren Zuständigkeiten. Code-Reviews, kollaboratives Arbeiten und automatisierte Tests können helfen, Probleme frühzeitig zu erkennen.

Folgenummer anpassen

Folgenummer anpassen

In dieser Folge sprechen wir über die Solid-Prinzipien und über Separation of Concerns.

Durch klare Verantwortlichkeiten und die Trennung von Code können wir unsere Anwendung erweiterbarer gestalten. Der Einsatz des Single Responsibility Principle sorgt dafür, dass Klassen nur eine Aufgabe haben. Das Open-Closed-Prinzip ermöglicht es uns, neuen Code hinzuzufügen, anstatt bestehenden zu verändern. Das Interface Segregation Principle macht Interfaces fokussierter. Das Dependency Inversion Principle verringert Abhängigkeiten zwischen Klassen.