Ein spannendes Interview mit Stefan Lieser von der Initiative
"Clean Code Developer" gibt es in der einhundertzweiten Episode des
Anwendungsentwickler-Podcasts. TL;DR Mit Stefan Lieser bespreche
ich, wie du als IT-Azubi Clean Code im Alltag umsetzt: durch kleine
Übungsaufgaben, regelmäßiges Lernen und gemeinsame Arbeit im Team.
Die Clean Code Developer Initiative ordnet ihre Prinzipien und
Praktiken in farbige Grade ein, mit denen du dich jeweils etwa drei
Wochen beschäftigst. Zu ihren vier Werten gehören Korrektheit,
Wandelbarkeit, Produktionseffizienz und kontinuierliches
Verbessern. Außerdem erfährst du, wie Flow Design beim Entwerfen
hilft und weshalb automatisierte Tests sowie klar getrennte
Aufgaben innerhalb von Methoden die Software verständlicher und
leichter veränderbar machen. Kapitelmarken [00:00:00] Einführung in
das Interview [00:01:14] Stefan Lieser stellt sich vor [00:02:40]
Clean-Code-Prinzipien sammeln und mit Katas üben [00:04:34] Clean
Code in Betrieben, Berufsschulen und IHK-Prüfungen [00:07:03]
Liesers Weg zu C# und seine Erfahrungen mit anderen Sprachen
[00:10:03] Trainings und Ausbildung bei der CCD School [00:11:23]
Workshopformate und langfristige Begleitung [00:14:27] Gemeinsam
als Team lernen [00:16:25] Qualität im eigenen Betrieb anstoßen
[00:19:22] Kontinuierlich lernen und Arbeitszeit dafür einplanen
[00:21:19] Clean Code in älteren Entwicklungsumgebungen [00:22:48]
Automatisierte Tests und die vier CCD-Werte [00:23:50]
Microservices und asynchrones Programmieren vorbereiten [00:26:48]
Wie die Clean Code Developer Initiative entstand [00:28:36] Farbige
Grade und der Kreislauf beim Lernen [00:30:16] Reihenfolge der
Bausteine und Einstieg im roten Grad [00:32:34] Prinzipien,
Praktiken und ihre vier Werte [00:34:32] Von einzelnen Prinzipien
zu Flow Design [00:37:05] Software mit Aktionen und Datenflüssen
entwerfen [00:39:21] Symbole und Code aus dem Flow-Design-Entwurf
[00:40:38] UML, TDD und gemeinsames Entwerfen im Team [00:44:32]
Code und Entwurf in Einklang halten [00:47:09] IOSP und das Abwägen
von Prinzipien [00:49:58] Flow Design und Domain-Driven Design
[00:52:01] Armbänder und weitere Hilfen für den Alltag [00:55:44]
Websites und Übungsaufgaben für den Einstieg [00:58:49] Bücher,
Testkurse und fachlicher Austausch [00:61:24] Fachvorträge und
Projektpräsentationen üben [01:02:32] Kontakt und Refactoring von
Legacy-Code [01:03:26] Zeit für fachliches Lernen einplanen
[01:04:31] Shownotes und Ausblick Inhalt Hier sind einige der
Fragen, die wir im Laufe des Gesprächs durchgegangen sind: Wie ist
dein Name und wo arbeitest du (falls gewünscht)? Wie bist du zur
Informatik bzw. Softwareentwicklung gekommen? Welche Ausbildung
bzw. welches Studium hast du im Bereich der Informatik absolviert?
Mit welcher/n Programmiersprache/n arbeitest du im Alltag? Was ist
deine Lieblingsprogrammiersprache und warum? Bildest du selbst
Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen? Was ist
das letzte Fachbuch mit Bezug zur Programmierung, das du gelesen
hast? Was ist dein absolutes Lieblingsbuch mit Bezug zur
Programmierung und warum? Welche Quellen kannst du für die Aus- und
Weiterbildung im Bereich Programmierung empfehlen und warum? Wer
braucht Microservices? Wie sollte man beim Entwurf einer Software
vorgehen? Welche Modellierungswerkzeuge sollte man einsetzen? Was
ist Flow Design? Was ist die Initiative "Clean Code Developer"? Was
ist der Sinn des CCD-Armbandes? Welches Prinzip findest du am
wichtigsten bzw. welches bietet den größten Mehrwert? Welche
Praktik findest du am wichtigsten bzw. welche bietet den größten
Mehrwert? Werden die Ideen hinter CCD deiner Erfahrung nach schon
großflächig in den Unternehmen eingesetzt oder ist hier noch viel
Aufklärungs-/Überzeugungsarbeit zu leisten? Sollten bereits
Auszubildende/Studenten mit CCD anfangen oder ist das eher etwas
für "fertige" Entwickler/-innen? Wie können auch Azubis/Studenten
schon CCD in ihren Alltag integrieren bzw. womit sollten sie
beginnen? Was können (gerade junge) Entwickler/-innen tun, wenn ihr
Unternehmen die Ideen hinter CCD nicht unterstützt? Muss CCD in
Unternehmen immer "von oben" mitgetragen werden oder können
Entwickler auch selbst damit anfangen? Wo kann man mehr über CCD
erfahren? Gibt es z.B. Kurse, Bücher, Konferenzen usw.? Wo können
die Hörer mehr über dich erfahren bzw. dich kontaktieren?
Literaturempfehlungen Auf Clean Code* basiert eigentlich das
gesamte Gespräch mit Stefan. Daher darf es natürlich nicht auf der
Buchliste fehlen! * Außerdem hat Stefan noch Refactoring*
empfohlen, um "alten" Code Schritt für Schritt besser zu machen. *
Um dabei gleich in Richtung etablierter Patterns zu arbeiten, ist
noch Refactoring to Patterns* zu empfehlen. * Und ein weiterer
Klassiker, den ich persönlich auch jedem Entwickler empfehlen kann,
wurde auch genannt: Working Effectively with Legacy Code*. * Links
Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Die
Initiative "Clean Code Developer" Trainings & Beratung rund um
Clean Code Development sowie Übungsaufgaben Refactoring von Legacy
Code Kostenloser Online Kurs zum Thema Unit Tests mit NUnit, über
2h Videos Cheatsheet zu Flow Design Zusammenfassung Stefan Lieser
und Clean Code in der Ausbildung Mit Stefan Lieser bespreche ich,
wie du als IT-Azubi zum/zur Fachinformatiker:in
Anwendungsentwicklung sauberen Code schreiben und deine
Arbeitsweise weiterentwickeln kannst. Er arbeitet freiberuflich,
schreibt unter anderem für die .NET Pro und bietet gemeinsam mit
Ralf Westphal Trainings über die CCD School an. Beide haben die
Clean Code Developer Initiative gegründet. Aus meinen IHK-Prüfungen
kenne ich Projektarbeiten, bei denen automatisierte Tests und
Continuous Integration kaum vorkommen. Auch Lieser erlebt in seinen
Trainings, dass Betriebe und Berufsschulen solche Arbeitsweisen
unterschiedlich vermitteln. Kleine Aufgaben geben dir Gelegenheit,
einzelne Prinzipien auszuprobieren, bevor du sie in einem echten
Projekt anwendest. Seine regelmäßig veröffentlichten Katas in der
.NET Pro folgen diesem Ansatz. C# und andere Sprachen Lieser hat
unter anderem mit C und C++ gearbeitet, sich mehrere Jahre mit
Netzwerken beschäftigt und später über VB6 zu C# gefunden. C# ist
seine Lieblingssprache, die er besonders gründlich kennt. Er
schätzt die zusammenhängend gestaltete Sprache und ihr zügiges
Weiterentwickeln unter Microsoft und Anders Hejlsberg. In seinen
Workshops begegnen ihm außerdem häufig Java und C++.
Clean-Code-Praktiken lassen sich auch in älteren Umgebungen
anwenden. In meinem Betrieb habe ich beispielsweise bei der Arbeit
mit Natural eine Versionsverwaltung mit eingeführt. Auch der Weg
vom Code bis zur produktiven Software lässt sich dort durch
Continuous Integration verbessern. Für ABAP berichtet Lieser aus
einem Training seines Kollegen, dass Unit-Tests zur verfügbaren
Umgebung gehören. Die Clean Code Developer Initiative Ende 2008
lasen Stefan Lieser und Ralf Westphal unabhängig voneinander Clean
Code von Robert C. Martin. Daraus entstand die Idee, bewährte
Prinzipien aus verschiedenen Quellen online zusammenzutragen. Die
Sammlung wuchs im Austausch mit der Community auf mehr als 40
Bausteine. Dabei bezeichnet Baustein sowohl ein Prinzip als auch
eine Praktik: Prinzip: Im fertigen Code lässt sich prüfen, ob es
eingehalten wurde. Eine Verletzung von DRY, also "Don’t Repeat
Yourself", wird beispielsweise durch kopierten Code sichtbar.
Praktik: Sie beschreibt, wie du arbeitest. Ob du beim
Test-First-Vorgehen zuerst den Test geschrieben hast, lässt sich
dem fertigen Code allein kaum eindeutig entnehmen. Vier Werte als
Grundlage Die Bausteine richten sich an vier Werten aus:
Korrektheit: Deine Software erfüllt die Anforderungen der
Kund:innen korrekt. Wandelbarkeit: Du kannst den Code auch nach
vielen Jahren verändern und um Funktionen ergänzen.
Produktionseffizienz: Der Aufwand bleibt gering, indem etwa Tests
und Builds automatisiert ablaufen. Auch Integration und Deployment
gehören dazu. Kontinuierliches Verbessern: Du lernst regelmäßig
dazu. Dieser Anspruch gilt ebenso für dein Team und den Betrieb wie
für die gesamte Branche. Automatisierte Tests verbinden Korrektheit
mit effizientem Arbeiten. Sie bilden außerdem eine Grundlage für
eine Pipeline, die Software bis in die produktive Umgebung bringt.
Mit den farbigen Graden arbeiten Die Sammlung ist auf fünf farbige
Grade verteilt: Rot, Orange, Gelb, Grün und Blau. Jeder enthält
ungefähr acht Prinzipien und Praktiken. Du beschäftigst dich etwa
drei Wochen mit einem Grad und achtest beim Programmieren gezielt
auf dessen Bausteine. Anschließend folgt der nächste Abschnitt.
Nach einem Durchlauf kannst du im weißen Grad etwa drei Wochen lang
alle Bausteine gemeinsam berücksichtigen. Danach beginnt der
Kreislauf erneut; vorgesehen sind mehrere Runden. Die Farben
orientieren sich am Regenbogen und kennzeichnen den aktuellen
Schwerpunkt beim Lernen. Im roten Grad stehen überwiegend
Bausteine, die du selbst anwenden kannst, etwa DRY.
Versionskontrolle gehört ebenfalls an den Anfang. Später folgen
anspruchsvollere Aufgaben oder solche, für die sich das Team
abstimmen muss. Toolgestützte, einfache Refactorings kommen früh
vor. Integrationstests stehen vor Unit-Tests, weil du sie auch bei
stark miteinander verbundenem Code schreiben kannst. Für Unit-Tests
musst du dich intensiver damit beschäftigen, Abhängigkeiten
aufzulösen. Gemeinsames Entwerfen erscheint im blauen Grad, da das
Team dafür eine gemeinsame Sprache lernen und üben muss. Lernen und
Üben im Betrieb Die CCD School hat unterschiedlich lange
Workshopformate ausprobiert. Daraus entwickelte sich ein Ansatz mit
einzelnen Trainingstagen und längerfristiger Begleitung: etwa sechs
bis zehn Termine über ein Jahr verteilt, häufig mit drei bis vier
Wochen Abstand. Während eines Trainingstags bearbeitet das Team
Aufgaben, zu denen es Entwürfe erstellt und Code schreibt. Im
anschließenden Review werden die Lösungen anhand der Prinzipien
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.