Clean Ausbildung für mehr Clean Code

Prosoz Herten GmbH hat im Jahr 2019 die Umsetzung der Ausbildung Fachinformatiker*in / Anwendungsentwicklung überdacht und ein neues leichtgewichtiges Konzept erarbeitet, damit die jungen Menschen bessere Möglichkeiten haben ihre eigenen Potenziale schon vor dem Berufseinstieg selber zu entdecken und über sich hinaus wachsen zu können.

Grundvoraussetzung dafür war ein positives Lernumfeld zu etablieren, indem unsere Azubis nicht nur Programmierkonzepte lernen und codieren, sondern auch
 Softwareentwicklungsprozesse erleben
 Das Vermittelte in Frage stellen, kritisch betrachten und den Sinn verstehen
 Lernen was Zusammenarbeit im Team wirklich bedeutet
 Selbstorganisiert und auch kooperativ lernen
 Persönlich wachsen
 Die zeitlosen und unverbrüchlichen Werte und Prinzipien des Software Engineering verinnerlichen
 Bewusstsein für Codequalität und Softwaredesign entwickeln
 Den Fokus auf das Schreiben qualitativ hochwertigen Codes legen

Wir begleiten die Azubis bei ihrer Entwicklung so eng. Gleichzeitig gewähren wir ihnen viele Freiheiten und schenken ihnen unser Vertrauen ohne Wenn und Aber.
Das Ergebnis sind aufblühende junge Menschen mit mehr Selbstbewusstsein, Eigenverantwortung, Mut und Bereitschaft mehr Verantwortung zu übernehmen und Dinge aus Überzeugung zum Besseren zu wenden.

Das Entwicklen eines Bewusstseins für Softwarequalität und eine Sensibilisierung für „Clean Code“ ist nur eine von vielen positiven Schlussfolgerungen.

Ich möchte euch das Garagenkonzept vorstellen, Impulse geben, und aufzeigen, wie Azubis schon in den ersten Monaten beginnen TDD, Softwarequalität, Softwareentwicklungsprinzipien, Softwaredesign, Schichtenarchitektur, Refactoring, Code-Reviews, Pair Programming, Code Katas und Clean Code kennenzulernen und damit Erfahrung zu sammeln.

Clean Code, Dirty Agile

Entwicklungsteams müssen Prinzipien und Praktiken bewusst einsetzen, um qualitativ hochwertige Softwaresysteme zu erstellen.
Interne Code-Qualität eines Softwaresystems hat eine enorme Auswirkung auf den wirtschaftlichen Erfolg eines IT-Unternehmens. Der Grad der Wartbarkeit und Erweiterbarkeit eines Systems hat eine direkte Auswirkung auf allen Feedback-, Kommunikations- und Handlungsebenen einer Organisation. Schlechte Code-Qualität bedeutet eine lange Time-to-Market, sie verursacht schlechte Kundenzufriedenheit, Geldverschwendung und große Frustration in den Teams und in der ganzen Organisation.
Die interne Codequalität fällt nicht vom Himmel. Darum beschäftigen sich viele Softwareentwickler und Tester mit den Themen wie Clean Code und Extreme-Programming-Techniken.
Aber Moment Mal! Waren solche Probleme nicht die Probleme von Wasserfall, also aus der Vergangenheit? Ist nicht mit SCRUM alles stets anders, besser und problemlos? Sollte agile Prozesse es nicht ermöglichen, vor allem erfolgreiche Produkte in einer dynamischen und komplexen Welt bauen zu können, die sich zu schnell verändert?
Agile Prozessmodelle wie SCRUM und Kanban können erst durch geeignete Entwicklungsmethoden, die die Qualität eines Produktes gewährleisten, zu effizienten Entwicklungsmodellen werden. Natürlich haben beide einen Beeinfluss aufeinander. Teams brauchen einen Rahmen, indem sie sich schlank bewegen und das Richtige richtig tun können. Aber immerhin, nicht wie der Prozess drum herum aussieht und beschrieben wird ist für den Erfolg entscheidend, sondern wie das Produkt im und vom Team hergestellt wird.
Daher finde ich es sehr wichtig, ein geeignetes Umfeld zu haben, damit Clean Code und XP Techniken effizient eingesetzt werden können. Das ist aber leider nicht immer der Fall und viele Entwickler leiden unter Pseudo-Agilität, in der das Experimentieren und die schnelle Feedback-Zyklen nicht möglich sind. Dazu kommt, dass alte zentralisierte Command-and-Control-Systeme nur einen anderen Namen bekommen haben. Diese heißen nicht mehr Manager sondern Master.
Auch mit SCRUM brauchen Entwickler, die zu wenig Einfluss und zu wenig Kontext haben, viel zu lange. Dabei entwickeln sie Produkte – auch noch mit schlechter Codequalität - die die Kunden eigentlich gar nicht haben wollen. Das hat unzufriedene Kunden, unmotivierte Entwickler und frustrierte Manager -pardon - Scrum Master zur Folge.
Das ist höchstwahrscheinlich eine „Dirty Agile“ Welt, in der die agilen Werte und Prinzipien nicht gelebt werden. Das wahre Potenzial von Clean Code kann in einem agilen Umfeld leichter ausgeschöpft werden. Meiner Sicht nach, braucht Clean Code ein wahres, authentisch agiles Umfeld. Aber was genau bedeutet agile Softwareentwicklung? Und wie ist es ursprünglich entstanden und evolviert?
In diesem Vortrag werden Antworten auf Fragen gegeben, die aus meiner Sicht im Zusammenhang mit agilen Werten, Prinzipien und Clean Code entstanden sind. Darüber hinaus werden ein paar Beispiele aus der Praxis präsentiert, um zu zeigen, wann agile „dirty“ sein kann.

Ich habe den Vortrag auf folgende Events gehalten:
https://www.dev-days-online.de/session/clean-code-dirty-agile/
https://www.ittage.informatik-aktuell.de/programm/2020/clean-code-dirty-agile.html
https://basta.net/agile-devops/clean-code-dirty-agile/

Code Kata - Open Closed Prinzip für erweiterbaren Code

In dieser gemeinsamen Code-Kata werden wir eine Anforderung so umsetzen, dass wir am Ende der Übung eine erweiterbare Architektur mit sauberem und wartbarem Code aufgebaut haben.

Der Fokus der Übung liegt nicht darauf, die Anforderung von Anfang bis Ende vollständig umzusetzen. Vielmehr geht es um den gemeinsamen Lernprozess, indem wir das Open/Closed Prinzip samt der dahinter stehenden Grundidee und seiner praktischen Relevanz kennenlernen, verstehen und üben.

Die Hauptsache ist, dass wir die Kata gemeinsam durchführen, mit- und
voneinander lernen und beim Lernen Spaß haben.

Ich habe eine umfangreiche Version als Workshop auf Clean Code Days in München im Jahr 2017 durchgeführt.
https://www.cleancode-days.de/files/cleancode/site/pdf/ccdet17_broschuere.pdf

Die Schöne und gleichzeitig die Bestie

Die schlechte Nachricht über User Stories ist:
Oft sind diese Stories nur plumpe Anforderungen, die sowohl das WAS als auch das WIE beschreiben. Unter anderem sind sie oft so detailliert, dass das Development-Team nicht mehr über das Nutzen nachdenken und oft den Blick des Endanwenders außer Acht lassen. Und User Stories dienen oft nicht den CCC-Regeln von Ron Jeffries (Erfinder dieser Technik).

Die gute Nachricht über User Stories ist:
Die User Storys können zu einem erfolgreichen Produkt mit mehr Mehr-Wert und mehr Nutzen führen. Ein Development-Team wird schneller und qualitativer, weil es sich auf das notwendige konzentrieren kann. Die Qualität der Arbeit wird definitiv steigen, weil ein gemeinsames Verständnis über das, was getan werden muss, früher entstehen wird.

In diesem Workshop wirst du in einen praktischen Einblick in das Arbeiten mit User Stories verschaffen. Du wirst die Grundlagen von User Stories, so wie die Prinzipien, die da hinter stehen, kennen lernen. Du wirst lernen, wie du User Stories mit guter Qualität schreiben, bewerten und zerteilen kannst.

Ich möchte dir viel Wissen aus der Praxis in einer sehr kompakten Schulung vermitteln. Egal, welche Rolle du in deinem Team spielst, dieser Workshop wird dir helfen!