Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

In unserem ersten Beitrag der Reihe „Softwarearchitektur verbessern“ greifen wir ein Thema auf, das in den Trainings der ITech Academy und auch in zahlreichen Blog- und Forenbeiträgen immer wieder kontrovers diskutiert wird: Clean Code als Architekturaufgabe. Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level versuchen wir, die teilnehmenden Architekten zur Entscheidungsfähigkeit hinzuführen, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 14.-16. November 2018 in Nürnberg
Weitere Infos: www.itech-progress.com/isaqb-improve/

Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

In unserem ersten Beitrag der Reihe „Softwarearchitektur verbessern“ greifen wir ein Thema auf, das in den Trainings der ITech Academy und auch in zahlreichen Blog- und Forenbeiträgen immer wieder kontrovers diskutiert wird: Clean Code als Architekturaufgabe. Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level versuchen wir, die teilnehmenden Architekten zur Entscheidungsfähigkeit hinzuführen, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 14.-16. November 2018 in Nürnberg
Weitere Infos: www.itech-progress.com/isaqb-improve/

NEU: ITech Academy Friends auf Facebook

NEU: ITech Academy Friends auf Facebook

Entdecken Sie die neue Facebook-Gruppe der ITech Academy und sichern Sie sich als Mitglied 10% Rabatt auf alle offenen Trainings von ITech Progress. Wie es geht? Treten Sie mit einem Klick unserer Gruppe bei und warten Sie auf Ihre Bestätigung durch unseren Administrator. Ab diesem Moment können Sie bei jeder Bestellung über die Website im Nachrichten-Feld das Kennwort “Academy Friends” eingeben und Sie erhalten automatisch den Rabatt auf Ihre nächste Rechnung.

Aber die Facebook-Gruppe ist weit mehr als ein Sparstrumpf für unsere Trainingsteilnehmer. Academy Friends werden laufend über aktuelle Entwicklungen, bevorstehende Trainings, den Auslastungsstatus der nächsten Schulungen oder über Änderungen informiert.

Interessiert? Dann klicken Sie den Button, um nach Ihrer Facebookanmeldung der Gruppe beizutreten.

Wir freuen uns auf Sie!

NEU: ITech Academy Friends auf Facebook

NEU: ITech Academy Friends auf Facebook

Entdecken Sie die neue Facebook-Gruppe der ITech Academy und sichern Sie sich als Mitglied 10% Rabatt auf alle offenen Trainings von ITech Progress. Wie es geht? Treten Sie mit einem Klick unserer Gruppe bei und warten Sie auf Ihre Bestätigung durch unseren Administrator. Ab diesem Moment können Sie bei jeder Bestellung über die Website im Nachrichten-Feld das Kennwort “Academy Friends” eingeben und Sie erhalten automatisch den Rabatt auf Ihre nächste Rechnung.

Aber die Facebook-Gruppe ist weit mehr als ein Sparstrumpf für unsere Trainingsteilnehmer. Academy Friends werden laufend über aktuelle Entwicklungen, bevorstehende Trainings, den Auslastungsstatus der nächsten Schulungen oder über Änderungen informiert.

Interessiert? Dann klicken Sie den Button, um nach Ihrer Facebookanmeldung der Gruppe beizutreten.

Wir freuen uns auf Sie!

Überlegen zerlegen: Softwarearchitektur mit der Flex

Überlegen zerlegen: Softwarearchitektur mit der Flex

Ob es ein kantiger Monolith ist, eine verschachtelte SOA oder auch nur ein sperriger Klotz von Anforderungen an ein neues Projekt: Software fachgerecht zu zerlegen ist hoch anspruchsvoll und will gelernt sein – gerade dann, wenn eine Microservicearchitektur das Ziel ist.

In der ITech Academy erledigen wir das souverän mit der FLEX. Die dreitägige, iSAQB-lizenzierte Schulung „Flexible Softwaremodelle (FLEX)“ stellt eine breite Palette an Methoden und Tools zur Verfügung, um gefragte Themen wie Microservices, Self-contained Systems und DevOps erfolgreich in die Praxis umsetzen zu können. Dabei geht es zunächst um die Entscheidungsfindung: In welchen Fällen sind Microservices überhaupt sinnvoll und wann lässt man lieber die Finger davon? Wo setzt man intelligent den Schnitt an, um nicht die Komplexität eines Monolithen und zusätzlich die eines verteilten Systems zu ernten? Was spricht für oder gegen den Einsatz von Domain-driven Design (DDD)? Mit welchen Risiken und Wechselwirkungen muss bei flexiblen Architekturen gerechnet werden und was bringen sie unter Gesichtspunkten wie Wirtschaftlichkeit, Effizienz und Skalierbarkeit unter dem Strich?

Auf Basis dieser und weiterer theoretischer Grundlagen führen praktische Übungen in die Arbeit mit FLEX-Architekturen ein und bieten erste Gelegenheit, das erworbene Wissen anzuwenden.
Das Flex-Training ist eines von aktuell zehn Modulen des Schulungsprogramms der ITech Academy zum Certified Professional for Software Architecture – Advanced Level (CPSA-A).

 

Für weitere Informationen:

Training „iSAQB Flexible Softwaremodelle (FLEX)“

Info „iSAQB CPSA Advanced Level (CPSA-A)“

 

Bildrechte:
“Cortadora de metal” von Carlos Castaneda Giron CC BY-SA 3.0 ], vom Wikimedia Commons

Das Doppelpack für die moderne Architektur

Das Doppelpack für die moderne Architektur

Trendreport: Flexible Architekturen

 

Während die Skyline unserer Softwarewelt nach wie vor von Monolithen geprägt ist, hat sich der Trend zu flexiblen Architekturmodellen mit Microservices, Continuous Deployment, DevOps und hohen Automatisierungsgraden auf möglichst allen Ebenen inzwischen durchgesetzt. Und in der Tat: kompaktere, weitestgehend autarke Softwaremodule mit eigenen spezialisierten Teams bieten eine Menge Vorteile – von der Konzeption über Entwicklung und Testen bis in die Wartung. Verbesserte Stabilität, adaptive Reaktion auf veränderliche Anforderungen, Effizienz- und Kostenvorteile in der Weiterentwicklung sind Argumente, bei denen jedes Entscheiderherz höher schlagen sollte.

Aus architektonischer Sicht ist eine flexible Sortwarearchitektur allerdings leichter gesagt, als getan. Welche Methodik ist für mein Projekt die richtige? Anhand welcher Kriterien lassen sich Module zielführend abgrenzen? Wie kann ich von Anfang an vermeiden, dass sich bei zusätzlichen oder sich verändernden Anforderungen mit der Zeit der berühmt-berüchtigte Big Ball of Mud bildet?

Für viele Softwarearchitekten ist Domain Driven Design (DDD) die Antwort auf diese und andere gängige Fragestellungen im Vorfeld einer flexiblen Architektur. DDD setzt konsequent auf die Fachlichkeit, und die liegt im Business des Unternehmens begründet, nicht im technischen Jargon des Entwicklerteams. Aus dem Business heraus lassen sich bereits in frühen Phasen des strategischen Designs inhaltliche und funktionale Einheiten als Bounded Contexts separieren. Aber auch im taktischen Design können sich sinnvolle Modularisierungsoptionen ergeben. So bildet die Fachlichkeit letztendlich die Basis für die Abgrenzung der Microservices und die Herausbildung dedizierter Teams.

Architekten, die ihr Handwerk in diese Richtung entwickeln möchten, finden in den Modulen Flexible Softwaremodelle (FLEX) und Domain Driven Design (DDD) ein starkes Doppelpack an iSAQB-lizenzierten Trainings, in denen alle relevanten Grundlagen anschaulich und praxisnah vermittelt werden. An der ITech Academy zählt die Kombination von FLEX und DDD bereits seit über einem Jahr zu den am stärksten nachgefragten, oft und gerne ergänzt durch das Modul Agile Softwarearchitektur (AGILA). Bei Interesse sollte an eine frühzeitige Anmeldung gedacht werden.

 

Weiterführende Links

Training iSAQB CPSA Domain Driven Design (DDD)

Training iSAQB Flexible Architekturmodelle (FLEX)

Training iSAQB Agile Softwarearchitektur (AGILA)

Vorteile

 

  • Fokussierung auf die Fachlichkeit des Unternehmens
  • Vereinfachte Modularisierung in Microservices
  • Verbesserte Stabilität
  • Adaptive Reaktion auf veränderliche Anforderungen
  • Effizienz- und Kostenvorteile