Interview
09.06.2022, 00:00 Uhr
"Es ist falsch, dass das Team die Verantwortung für die gesamte Architektur hat"
Code-Behind ist böse und das ganze Team haftet für die passende Architektur: Diese beiden Aussagen stellt Developer-Week-Sprecher David Tielke infrage. Im Interview mit dotnetpro sagt er, was die Lehren aus der Praxis sind.
(Quelle: David Tielke)
Du hältst auf der Developer Week eine vierstündige DevSession zum Thema Kodierrichtlinien. Was verstehst du darunter?
David Tielke: In der Softwareentwicklung kennen wir als Entwickler die Vorgaben aus funktionalen und nichtfunktionalen Anforderungen. Die Richtlinien sind eine Ergänzung dazu und stellen die Anforderungen aus Sicht des Unternehmens dar. Das heißt, sie geben vor, welche Muster wir verwenden dürfen, wie die Programmiersprache angewendet werden soll, welche Entwicklungs- und Entwurfsprinzipien zu berücksichtigen sind und vieles weitere. Nur mit so einem Dokument kann wirklich hochqualitative und risikoreduzierte Softwareentwicklung durchgeführt werden.
Ein unbekannter Entwickler hat einmal gesagt: „Keinen Code lese ich so gut wie meinen.“ Jetzt plädierst du dafür, dass sich alle Entwickler im Team verbiegen und Code nach den gleichen Richtlinien schreiben. Gibt es dabei nicht zu viele Reibungsverluste?
David Tielke: Ich denke, für diese Antwort muss man den gesamten Kontext der modernen Softwareentwicklung betrachten: Heute wird aufgrund großer Projekte, unterschiedlichster Technologien und einer enormen Komplexität die Software fast immer in Teams entwickelt. Und genau wie im Sport muss ein solches Team eine gemeinsame Spielidee mit Leitplanken und Regeln haben, um wirklich erfolgreich zu sein. Am Ende geht es ja nicht nur um den eigenen Quellcode, sondern auch um den der Kollegen und nichts wäre schöner, als wenn der genau so gut lesbar wäre, wie mein eigener Quellcode – und genau das ist der Punkt bei Richtlinien.
Kodierrichtlinien sind ein Baustein für Softwarequalität - ein weiteres Thema, dem du eine Session widmest. Wenn du die wichtigsten drei Dinge nennen müsstest, die für optimale Softwarequalität ausschlaggebend sind, welche wären das?
David Tielke: Zunächst ist es wichtig, dass es einen an das Unternehmen, das Produkt und das Team angepassten Entwicklungsprozess gibt. Ob es sich dabei um Scrum, Kanban oder etwas Selbstgestricktes handelt, ist egal – die Hauptsache ist, dass der Prozess im Unternehmen optimal funktioniert.
Am Anfang eines solchen Prozesses werden die Anforderungen aufgenommen, welche später der hauptsächliche Input für viele weitere Prozessschritte ist, zum Beispiel die Architektur, die Implementierung und das Testen.Und auch wenn hier mit wenig Maßnahmen bereits riesige Erfolge erzielt werden können, gibt es leider bei so gut wie jedem Projekt erheblichen Nachholbedarf.
Der dritte Punkt ist natürlich die Architektur – weil wir hier langfristig dafür sorgen, dass unser Projekt funktioniert, also gewartet und einfach weiterentwickelt werden kann. Hat man keine oder keine ausreichende Architektur, endet das immer in einem unfassbar teuren Refactoring oder sogar in einem kompletten Rewrite von Softwareprojekten.
„Ein Projekt, ein Architekt“, ist ein anderes Zitat des unbekannten Entwicklers. In dem Workshop, den du über Softwaredesign hältst, stärkst du aber allen Teammitgliedern den Rücken, wenn es um das Design der Anwendung geht. Warum?
David Tielke: Der eine nennt es „Rücken stärken“, ich nenne es eher „in die Pflicht nehmen“. Die Architektur einer Anwendung unterteilt sich in die System- und Softwarearchitektur welche größtenteils dafür Verantwortlich sind, die Unternehmens und Produktvision umzusetzen. Hier bin ich total bei der alten Sichtweise, dass in jedem Projekt die Rolle des Architekten diese Strukturen übernehmen sollte – ob dies eine dedizierte Person ist oder einzelne Softwareentwickler die Rolle übernehmen ist dabei nicht entscheidet. Wichtig ist, dass die Ausbildung in diesem Bereich stimmt.
Daneben gibt es die dritte Art, das Software-Design. Hier geht es um die nachhaltige Implementierung von funktionalen Anforderungen mit Methoden, Klassen und Komponenten. Hier ist JEDER Entwickler gefordert das ganze mit einem Design zu implementieren, damit der geschriebene Quellcode erweiter-, wart-, testbar und so weiter ist. Sehr kritisch sehe ich die moderne Aussage, dass ein gesamtes Team die Verantwortung für die gesamte Architektur hat – dies ist in meinen Augen schlichtweg falsch und führt fast immer dazu, dass Projekte irgendwann neu entwickelt oder umgeschrieben werden müssen.
Es gab mal die Epoche der Patterns, in der ein Entwickler nur etwas galt, wenn er jede Menge Entwurfsmuster in seinen Code gestreut hat. Wie sieht es da heute aus?
David Tielke: Diese Aussage war und ist schon immer falsch und war in meinen Augen auch nie so gedacht und hat sich irgendwann verselbstständigt. Sowohl für die System- und Softwarearchitektur als auch für das Softwaredesign gibt es zwei essenzielle Grundlagen: die Modularisierung und die Entkopplung. Damit kann fast jedes Problem in der Architektur gelöst werden – durch sogenannte Entwurfsentscheidungen. Diese Entscheidungen erzeugen immer positive Effekte aber auch immer negative.
Wichtig ist es in der Architektur, dass ich diese negativen Effekte erkenne und gegebenenfalls durch weitere Entscheidungen kompensiere. Patterns kürzen diesen Prozess hin zu vermeintlich fertiger Lösung ab, ohne dabei die negativen Effekte aufzuzeigen. Das führt dazu, dass diese Risiken unerkannt in Projekten existieren und irgendwann für enorme Probleme sorgen. Deshalb erst die architekturellen Grundlagen lernen und wenn man das verstanden hat, sollte man sich an das Thema der Muster ranwagen.
So hilfreich Design Pattern sein können, bergen sie aber auch Gefahren, wie du in einem Video auf deinem Youtube-Kanal feststellst. Welche sind das denn?
David Tielke: Ich denke das erklärt sich am besten an dem Beispiel des Design Pattern MVVM, also Model-View-ViewModel, eines der beliebtesten Patterns im Bereich WPF und gefühlt mittlerweile der de-facto Standard in solchen Projekten.
Nahezu jeder meint, dass Code-Behind böse ist und nur mit MVVM die Oberflächenlogik und die eigentliche View voneinander getrennt werden können. Also wird unfassbar viel Aufwand und teilweise enorm viel Komplexität in die Umsetzung mit MVVM gesteckt weil „man das heute eben so macht in WPF“.
In Wirklichkeit ist MVVM aber ein Entwurfsmuster um zwei Dinge zu erreichen: die Austauschbarkeit der View (habe ich in der Praxis noch nie erlebt) und die Testbarkeit der Oberflächenlogik im ViewModel. Benötigt man weder die Austauschbarkeit der View noch möchte man Unit-Tests für die Oberflächenlogik schreiben, hat man keinen Nutzen auf der einen Seite aber eine hohe Komplexität auf der anderen Seite und damit eine geringere Entwicklungsgeschwindigkeit. Also ein Muster sollte erst dann eingesetzt werden, wenn man alle Vorteile aber eben auch alle Nachteile kennt.
David Tielke ist seit über 10 Jahren freiberuflicher Berater, Coach und Trainer auf dem Microsoft-Technologiestack und dabei zertifizierter Experte für die Themen Architektur und Softwarequalität. Er berät und schult seine Kunden europaweit und ist als Sprecher auf zahlreichen Konferenzen sowie als Fachautor unterwegs. Informationen finden Sie auf seinem Blog
Developer Week ist die große Entwicklerkonferenz in Nürnberg. Fünf Tage lang können sich Softwareentwickler zu Themen wie Architektur, .NET, Web, Datenbanken oder Softskills fortbilden. 150 Sprecher, 30 Themenstränge, DevSessions und Workshops formen das Programm. Sie findet dieses Jahr vom 4. bis 8. Juli statt.
